Mozilla have lost their mind - Part 2

Mason_Wheeler

There's an entire forum here dedicated to calling a database shit, primarily because it can't distinguish between "" and null. Maybe you should read some of the posts and enlighten yourself.

Interesting. First post, apparently stickied, is "The empty string IS NULL". The first post shows that this is problematic because... Oracle's equality test is poorly implemented in this case. (Implementation issue; not a problem inherent in empty strings being equal to null.) And on the first page, a few posts down, second post by Murphyman, he explains exactly why this is not a bad idea in theory, and I don't think I could do better than his explanation. This is not a bad idea; this is a bad implementation of a good idea.

There's also the whole "you can box any variable type and make it nullable in .net" thing.

Again, simply because you can do something doesn't necessarily mean that you should, or that it makes any sense if you do do it.

blakeyrat

@Mason Wheeler said:

I'm sorry. I'm usually quite good at communicating and explaining things, and I really don't understand why nothing I'm saying seems to be getting through here. It's like there's some fundamental piece of experience that most of you don't have, and without it it's impossible to establish the necessary common ground required to exchange ideas effectively. Most of these "mysterious things that I know" are fundamentals to me, things that are so obvious they don't really need to be explained.
I sincerely apologize if that causes difficulty for the rest of you. That's honestly not my intention.

Uh, you still didn't answer the question there, buddy.

Sutherlands

@Mason Wheeler said:

So what do you mean by short-circuiting vs. non short-circuiting, then? Because as I pointed out, (non) short-circuiting is meaningless when applied to non-boolean operations, and I've never seen an example of where you would want a non short-circuiting boolean evaluation.

Let me scroll up.@Sutherlands said:

In most cases probably true. That doesn't mean that having both is "baggage", or that it isn't useful.

I'm sorry. I'm usually quite good at communicating and explaining things, and I really don't understand why nothing I'm saying seems to be getting through here. It's like there's some fundamental piece of experience that most of you don't have, and without it it's impossible to establish the necessary common ground required to exchange ideas effectively. Most of these "mysterious things that I know" are fundamentals to me, things that are so obvious they don't really need to be explained.

I sincerely apologize if that causes difficulty for the rest of you. That's honestly not my intention.

Yeah, you're... quite good at explaining things. So far, you've convinced... nobody of... nothing. Hmm, maybe you're not so good, eh? You know you've lost when someone asks you for an example and your response is, "It's too complicated for you guys."

Your example for #3 is the perfect response to your question about #1. You've created a new string that contains no information, which is therefore functionally indistinguishable from NULL (which means "no information"), and yet because it's an object and not something sensible like an array of chars, it can exist in a nonsensical state where it contains no information but is not NULL. That will make all your string handling code more complicated than it needs to be.

"Something sensible like an array of chars"... hmm, so you mean I should be able to do this?

String instance = new String("something");

Assert.AreEqual(instance[1] == 'o'); //true

Also, First Name = "Jim", Middle Name = NULL, Last Name = "Bob"

Does he have a middle name, or was it just not entered yet? With your craptastic way, we don't know.

Can you give me an EXAMPLE of where string handling is more difficult? Perhaps we have to use String.IsNullOrEmpty or String.IsNullOrWhitespace instead of == null? Yeah, I have no idea what those first two things mean, they're way less understandable.

You're so amazingly stupid. I must be being trolled.

There is something, I'm not quite understanding with regards to the Data Access example.

First, core concepts, we all know Tables, Rows, and Fields/Columns.

What I'm failing to understand is how Delphi automatically makes it unnecessary to lookup the field values by name? Isn't that sort of a requisite? Even if the syntax allows you to refer to it as a property or field of the column, there is still a lookup being done, either at that point, or when the data was returned to the component.

admittedly I haven't worked with databases much in C#, though.

But, from what I understand, the catching point is the assignment from the fields to the created object:

object.PropertyName= Row["PropertyName"] basically.

This usually occurs as the data is loaded. I'm pretty sure you can deserialize a object graph directly from a relational database but I'm not sure about that.

Now, if I understand it, Delphi let's you access the Rows like this:

Row.PropertyName

Basically, as a method/field.

But this is what I don't understand- how does this save a lookup? The fact is, regardless of the language in use, the database still gives it the information as a set of fields that need to be looked up by name. In C#, since Field is a reference type, you can cache that value- or even use extension methods in some capacity for this, and store the references to teh appropriate fields in the class and then return those values in properties you create to match the fields. Sure, it's not generated by the language, but it's the same idea. I also highly doubt the Database code used to handle this stuff isn't somehow tweaked in such a way to make it work well. There are a bajillion different templates/generics and other classes designed for use with datasets, I find it hard to believe that while creating this advanced framework for dealing with databases they didn't optimize the actual accessing of the data, particularly since anonymous types practically perform that function (providing quick field lookup) in much the same way as the manual method that stores then in member variables.

@Mason Wheeler said:

Because C# fails on several points. It's C-based syntax is difficult to read, and it carries a lot of baggage from C even though it's fixed the real problems behind them, (there is no good reason why any modern language should still need two different versions of the and and or operators, for example,)

one short circuits for boolean expressions. One is for bit-bashing, particularly useful when dealing with flags. Any other "baggage" from C?

A bug like that is literally impossible without a runtime that defines strings as something way more complicated than they need to be.

String are complicated. They are a sequence of characters, but there is also encodings, unicode code points, multi-byte character sets, and any number of other things that need to be dealt with. Characters need to be converted to the appropriate locale and culture settings, etc. Most, if not all, languages oversimplify Strings to the point that most people don't use them "properly". C# makes the functionality to use them properly "available" (can't speak for Delphi, since all I have (now) is Delphi Prism which uses the same String object from what I can tell). Additionally, I'm not really sure I follow on the "C# makes them more complicated" argument. C# has Char and String, Delphi, from what I can tell, has Char, which only ever holds 1 byte, WideChar, which uses the "International alphabet" (whatever the fuck that means, is that how they "simplify" the term Unicode?) AnsiChar, which from what I've read is exactly the same as Char (which is a bit weird, this might be old docs). ShortString, which is basically Turbo Pascal's shitty "you only ever need 255 characters" String that has one byte for length and the rest string elements. No idea if those elements are represented using AnsiChar's or WideChar. String, which holds Char's up to any size desired (again, is this the Char or the WideChar, or the AnsiChar?) There is AnsiString (which according to the doc here holds AnsiChar's, so I guess we can safely say that the normal String doesn't, but since the standard Char type has the same description as the AnsiChar type "small alphabet" (whatever that means). And then there is WideString, which graciously is a bit more self-documenting.

So give all that, you have to choose which kind of character to use, and which kind of string to use for anything that needs strings, then you have to worry about whether somebody might try to put "Big alphabet" characters into your small alphabet char, whatever the fuck that means. Whereas in C# (or .NET, or hell even java) you basically just use the provided String object and don't worry about the details of how those characters are stored unless they directly concern you. I'm not trying to say that all these different string and char implementations are bad, they just sure as hell don't support your argument that .NET strings are more "complicated" to use, and given what I noted above, string [i]are[/i] complicated.

adding to this, is the immutability. It simplifies ones mental model of strings and how they work. An immutable object can be in exactly one state, the state in which it was created. If you make sure that all constructors establish class invariants, then it is guaranteed that these invariants will remain true for all time, with no effort on your part. C# (and .NET) provide the StringBuffer and associated objects for those times when you need the extra performance afforded from reusing the same memory block and just plopping data on the end (rather then copying everything as would occur with standard string concatenation... although I think that might be compiled into appropriate calls to a StringBuffer, not sure).

The biggest- and IMO most important reason- to have strings immutable? Thread-safety. Sure, you can have thread-safe mutable string types, but an immutable object is automatically thread-safe, because it's not changable. So not only does having the String object being immutable give you guaranteed invariants when forming a mental model for your code, but it also simplifies multi-threaded programming. And if anything doesn't need additional complications, it's multi-threading.

My point is, there are advantages to having an immutable string type that you are probably ignoring due to selective bias- "Delphi does is way X, this other language does it Y, therefore Y is wrong and broken and stupid" isn't a particularly powerful argument.

Mason_Wheeler

@Sutherlands said:

@Mason Wheeler said:
So what do you mean by short-circuiting vs. non short-circuiting, then? Because as I pointed out, (non) short-circuiting is meaningless when applied to non-boolean operations, and I've never seen an example of where you would want a non short-circuiting boolean evaluation.
Let me scroll up.@Sutherlands said:
In most cases probably true. That doesn't mean that having both is "baggage", or that it isn't useful.

I'm sorry. I'm usually quite good at communicating and explaining things, and I really don't understand why nothing I'm saying seems to be getting through here. It's like there's some fundamental piece of experience that most of you don't have, and without it it's impossible to establish the necessary common ground required to exchange ideas effectively. Most of these "mysterious things that I know" are fundamentals to me, things that are so obvious they don't really need to be explained.

I sincerely apologize if that causes difficulty for the rest of you. That's honestly not my intention.

Yeah, you're... quite good at explaining things. So far, you've convinced... nobody of... nothing. Hmm, maybe you're not so good, eh? You know you've lost when someone asks you for an example and your response is, "It's too complicated for you guys."

Sorry to disappoint you. It's not my fault if you guys don't understand the fundamentals. I'm not a CS professor or something...

Your example for #3 is the perfect response to your question about #1. You've created a new string that contains no information, which is therefore functionally indistinguishable from NULL (which means "no information"), and yet because it's an object and not something sensible like an array of chars, it can exist in a nonsensical state where it contains no information but is not NULL. That will make all your string handling code more complicated than it needs to be.

"Something sensible like an array of chars"... hmm, so you mean I should be able to do this?

String instance = new String("something");

Assert.AreEqual(instance[1] == 'o'); //true

No, I don't mean your string should be an object with a default property that provides syntactic sugar to make it look like it's an array when it's actually an object. I mean it makes more sense to have it actually be an array.

Also, First Name = "Jim", Middle Name = NULL, Last Name = "Bob"

Does he have a middle name, or was it just not entered yet? With your craptastic way, we don't know.

Congratulations, you can create a contrived example. This does not explain why I should care about it. If it "hasn't been entered yet," then we're dealing with end users and some sort of user interface. You don't show stuff like "NULL" to an end-user, so if it hasn't been entered yet, it'll be blank, and if there's no middle name to enter, then... it'll be blank! So does any meaningful, useful difference exist?

Can you give me an EXAMPLE of where string handling is more difficult? Perhaps we have to use String.IsNullOrEmpty or String.IsNullOrWhitespace instead of == null? Yeah, I have no idea what those first two things mean, they're way less understandable.

So instead of a simple, intuitive check against null, which is what you do to find out if any other object ever contains no information, you have two special methods that only applies to strings. You first have to know that these exist. Then you have to know when to use the one and when to use the other. Then you have to actually use them, and their syntax is very strange. They're static methods on the string class that take a single argument of type string. Why is it not a simple instance method that takes no arguments besides this? ...oh, right. Because this might be null! (Which actually still doesn't make any sense. Calling a non-virtual method on a null reference shouldn't raise an exception unless you try to dereference this. It could be trivially implemented as something like "return ((this == NULL) || (this.length == 0));" but it's a class method instead, which is really awkward.)

You don't see how this makes string handling more complicated than it needs to be, when a simple "if myString == NULL" should be good enough?

Sutherlands

@Mason Wheeler said:

Sorry to disappoint you. It's not my fault if you guys don't understand the fundamentals. I'm not a CS professor or something...

You still haven't answered the question.

Congratulations, you can create a contrived example. This does not explain why I should care about it. If it "hasn't been entered yet," then we're dealing with end users and some sort of user interface. You don't show stuff like "NULL" to an end-user, so if it hasn't been entered yet, it'll be blank, and if there's no middle name to enter, then... it'll be blank! So does any meaningful, useful difference exist?

Or you're dealing with a database that just got a new row and if it's null you have to ask the user for it. Etc... just because you're not very smart doesn't mean something doesn't exist.

So instead of a simple, intuitive check against null, which is what you do to find out if any other object ever contains no information, you have two special methods that only applies to strings. You first have to know that these exist. Then you have to know when to use the one and when to use the other. Then you have to actually use them, and their syntax is very strange. They're static methods on the string class that take a single argument of type string. Why is it not a simple instance method that takes no arguments besides this? ...oh, right. Because this might be null! (Which actually still doesn't make any sense. Calling a non-virtual method on a null reference shouldn't raise an exception unless you try to dereference this. It could be trivially implemented as something like "return ((this == NULL) || (this.length == 0));" but it's a class method instead, which is really awkward.)

You don't see how this makes string handling more complicated than it needs to be, when a simple "if myString == NULL" should be good enough?

I'm smart enough to understand what string.IsNullOrEmpty does. Also, guess what an instance method that doesn't reference the 'this' argument is? A static method!

"Which actually still doesn't make any sense." It doesn't make sense that an object can be null?

"It could be trivially implemented as something like "return ((this == NULL) || (this.length == 0));"" It is! YAY!

And actually, it's an extension method, but I won't go into that since you're not quite smart enough to understand it.

Mason_Wheeler

First off, thank you for taking a reasonable tone. It makes responding to your questions a lot less stressful.

@BC_Programmer said:

There is something, I'm not quite understanding with regards to the Data Access example.
First, core concepts, we all know Tables, Rows, and Fields/Columns.
What I'm failing to understand is how Delphi automatically makes it unnecessary to lookup the field values by name? Isn't that sort of a requisite? Even if the syntax allows you to refer to it as a property or field of the column, there is still a lookup being done, either at that point, or when the data was returned to the component.

It doesn't. Looking back, I can see how what I wrote might have come across that way, but what I meant to say is that some of the other examples being given tried to make it look like C# had some magical way to get around this requirement, and that I didn't think any such thing exists. (Even in Delphi.)

What Delphi does that's useful in this case is provide virtual constructors and virtual class methods that the compiler can bind at compile-time, to keep the overhead of dynamic lookups and dynamic invocation to an absolute minimum, which really comes in handy when retrieving large amounts of data for a user, because that overhead can and does add up to noticeable delays, and no one wants to waste time staring at a crHourglass.

@Mason Wheeler said:

Because C# fails on several points. It's C-based syntax is difficult to read, and it carries a lot of baggage from C even though it's fixed the real problems behind them, (there is no good reason why any modern language should still need two different versions of the and and or operators, for example,)
one short circuits for boolean expressions. One is for bit-bashing, particularly useful when dealing with flags. Any other "baggage" from C?

As I pointed out before, since C# has a real boolean type, and trying to and or or a boolean and a number is nonsensical, there's no reason why this needs to be represented by two different sets of operators. The compiler should be able to tell the difference.

A bug like that is literally impossible without a runtime that defines strings as something way more complicated than they need to be.

String are complicated. They are a sequence of characters, but there is also encodings, unicode code points, multi-byte character sets, and any number of other things that need to be dealt with. Characters need to be converted to the appropriate locale and culture settings, etc. Most, if not all, languages oversimplify Strings to the point that most people don't use them "properly". C# makes the functionality to use them properly "available" (can't speak for Delphi, since all I have (now) is Delphi Prism which uses the same String object from what I can tell). Additionally, I'm not really sure I follow on the "C# makes them more complicated" argument. C# has Char and String, Delphi, from what I can tell, has ... <snip>

What Delphi has is the ability to deal easily with both Unicode and non-Unicode strings, since there's a whole lot of string data out there that's not in Unicode format. Here's the rundown:

AnsiChar = 1-byte character.

WideChar = 2-byte UTF-16 character.

ShortString = classic Pascal string. Limited to 255 bytes in length. Included for backwards compatibility purposes only and not recommended for new code. (This is why the name "string" does not map to it anymore.)

AnsiString = string made of AnsiChars, for dealing with non-Unicode text.

WideString = An easier-to-understand alias for COM's BSTR type, which is a UTF-16 Unicode string, made up of WideChars

UnicodeString (included in Delphi 2009 and later) = a native UTF-16 string type with several technical advantages over the BSTR format, made up of WideChars.

Char = An alias that maps to AnsiChar before Delphi 2009 and WideChar afterwards.

String = An alias that maps to AnsiString before Delphi 2009 and UnicodeString afterwards.

None of this requires strings or chars to be objects.

Whereas in C# (or .NET, or hell even java) you basically just use the provided String object and don't worry about the details of how those characters are stored unless they directly concern you.

Yeah, but what happens when they do? How do you work with ASCII data when you only have one string type and it's Unicode-only?

adding to this, is the immutability. It simplifies ones mental model of strings and how they work. An immutable object can be in exactly one state, the state in which it was created. If you make sure that all constructors establish class invariants, then it is guaranteed that these invariants will remain true for all time, with no effort on your part.

Yes, I've heard the arguments for immutable data types before. What I've never heard is a convincing reason why the "problems" that immutability is supposed to prevent are 1) so severe that it is worth it to give up the power of mutability and 2) any worse than the new problems created by having to use all sorts of complicated abstraction inversions to work around not being able to use mutable data types.

@John Hughes said:

The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous. To those more interested in material benefits, these “advantages” are not very convincing. Functional programmers argue that there are great material benefits … [but] this is plainly ridiculous. If omitting assignment statements brought such enormous benefits then FORTRAN programmers would have been doing it for twenty years. It is a logical impossibility to make a language more powerful by omitting features, no matter how bad they may be.
-- Why Functional Programming Matters

The biggest- and IMO most important reason- to have strings immutable? Thread-safety. Sure, you can have thread-safe mutable string types, but an immutable object is automatically thread-safe, because it's not changable. So not only does having the String object being immutable give you guaranteed invariants when forming a mental model for your code, but it also simplifies multi-threaded programming. And if anything doesn't need additional complications, it's multi-threading.

Yes, but making a mutable string thread-safe is trivial. Just have the compiler enforce reference counting with copy-on-write semantics, and make sure that it uses atomic increments and decrements for the reference counting, and the problem is gone. This is something the compiler should be able to handle; the user shouldn't have to worry about it at all.

fatbull

@toth said:

@Mason Wheeler said:
Two, it's immutable. (Seriously, what idiot thought that was a good idea?)
http://en.wikipedia.org/wiki/String_interning

Another aspect: Security.

If non-privileged code can call privileged code, the callee usually has to double-check its arguments (e.g., verify file names). But this is impossible to do correctly if arguments can change any time (e.g., after the check but before the actual work). Immutable objects (without overridable methods) are a simple solution to this problem.

Mason_Wheeler

@Sutherlands said:

Congratulations, you can create a contrived example. This does not explain why I should care about it. If it "hasn't been entered yet," then we're dealing with end users and some sort of user interface. You don't show stuff like "NULL" to an end-user, so if it hasn't been entered yet, it'll be blank, and if there's no middle name to enter, then... it'll be blank! So does any meaningful, useful difference exist?
Or you're dealing with a database that just got a new row and if it's null you have to ask the user for it. Etc... just because you're not very smart doesn't mean something doesn't exist.

This was already explained quite well in the "empty string IS NULL" thread in the post I commented on before. Either you need to have a value in this string or you don't. Having a non-null empty string is equivalent to saying "I both do and do not care whether a value exists for this string or not," which is a logical contradiction. (Come to think of it, that would be a pretty good way to confuse a malevolent AI. It's probably heard all the old cliches like "this sentence is false" and "does the set of all sets contain itself?" before, but this is a new one. "What is the meaning of a non-null empty string?") :D

I'm smart enough to understand what string.IsNullOrEmpty does. Also, guess what an instance method that doesn't reference the 'this' argument is? A static method!

Yes, I know what a static method is. How does that definition have anything at all to do with what we're talking about?

"Which actually still doesn't make any sense." It doesn't make sense that an object can be null?

No, it doesn't make sense that a non-virtual method should have to be made a static method and not an instance method simply because there is an expected use case where the this reference could be null.

"It could be trivially implemented as something like "return ((this == NULL) || (this.length == 0));""
It is! YAY!

And actually, it's an extension method, but I won't go into that since you're not quite smart enough to understand it.

And actually, it's a static method that doesn't have a this parameter. And I know exactly what extension methods are. (They were invented by the Delphi team for the Delphi.NET project to make certain binding techniques work.) Which makes me wonder, how did .NET code deal with strings being null or empty before they added the extension method?

blakeyrat

@Mason Wheeler said:

Sorry to disappoint you. It's not my fault if you guys don't understand the fundamentals. I'm not a CS professor or something...

Uh, you still still didn't answer the question there, buddy.

tOmcOlins

DelphiHadItFirst(TM)

And you can use & and | with boolean types in C#, which I have found useful on several occasions, mostly with |=.

dhromed

@Mason Wheeler said:

it can exist in a nonsensical state where it contains no information but is not NULL. That will make all your string handling code more complicated than it needs to be.

I can call string methods on an empty string without needing yet another null check or error trap. My string handling code is therefore less complicated.

Sorry for the off-topic post, but coming back to the subject of Mozilla's nonsensical behavior of late, I have just been greeted with Firefox being updated to version 5.0 even though I distinctly recall having told it repeatedly that I did not want it to update just yet. Thank you Mozilla!

I had two of my add-ons report as incompatible. One is my own and I easily edited the install.rdf, but the other I had to extract the .xpi, edit the install.rdf, rename the original .xpi, recompress again.

Only to be greeted with an Add-ons Manager without those add-ons listed. Where the hell have they gone?

The_Assimilator

Mason, either you're the world's biggest troll or you truly have difficulty comprehending the difference between NULL and blank and why that distinction is necessary. If the latter, you shouldn't be allowed to program.

@Mason Wheeler said:

What Delphi does that's useful in this case is provide virtual constructors and virtual class methods that the compiler can bind at compile-time, to keep the overhead of dynamic lookups and dynamic invocation to an absolute minimum, which really comes in handy when retrieving large amounts of data for a user, because that overhead can and does add up to noticeable delays, and no one wants to waste time staring at a crHourglass.

Yes but what "overhead" are you avoiding here? anonymous types + LINQ provide the same binding, which is compile time Field references. And if the table format is unknown at compile time, you can add your own members that store field references that are initialized when you read from the DB. The lookup work still has to be done, and from what I can tell the standard practices of most modern languages make sure that is done once and only once.

@Mason Wheeler said:

What Delphi has is the ability to deal easily with both Unicode and non-Unicode strings, since there's a whole lot of string data out there that's not in Unicode format. Here's the rundown:

Yeah went over those, except the UnicodeString. Why did it take until 2009 I wonder to add unicode support? But yeah that's in the language now so I guess I ought to follow my previous note that we can't compare what they used to be... :P

Yeah, but what happens when they do? How do you work with ASCII data when you only have one string type and it's Unicode-only?

C#'s string type isn't Unicode only. You can specify an encoding in the Constructor. for .NET 3.5 support is for ASCII, UTF7,UTF8,UTF16, UTF32, BIgEndianUnicode, And Unicode. IF you don't specify, then the safe assumption is you just want to store strings; if you do, you want to store/work with strings in that format. The Actual character encoding is abstracted away from the string, because a string is just a sequence of characters. It shouldn't be concerned with how the individual characters are stored. Because it's a primitive type in Delphi, it "has" to be concerned. (can you deal with BigEndianUnicode in Delphi? Ir maybe they will add the BigEndianUnicodeString type in 2012?

What I've never heard is a convincing reason why the "problems" that immutability is supposed to prevent are 1) so severe that it is worth it to give up the power of mutability and 2) any worse than the new problems created by having to use all sorts of complicated abstraction inversions to work around not being able to use mutable data types.

The aforementioned security concern is important, particularly in the case of String being a class.

Basically:

-Strings are classes because they represent a complex data type. They are fundamentally a list of chars, if it wasn't a class, it would probably need to concern itself with the internal storage and length of particular Encodings. Why should "String" be a primitive value type, and yet List<T> is a class type? They are fundamentally the same thing- a list of values. the char type in .NET, by the way, isn't a reference type, or a class. it's a value-type struct. When you assign values of type char you are in fact dealing with primitive types. A String is basically a list of chars, and Lists are Objects in any language I've seen. (one could make an argument for them being arrays, but why aren't arrays abstracted into lists?

-As a result of Strings being a class type, their values are reference types and therefore if they were mutable their values could be changed randomly in other threads or changed to circumvent security checks or other checks.

You want a mutable string type in C#, you are quite welcome to it; it's called char[], or, you could use a StringBuilder, I guess. It's a bit more work to deal with but when you want to work with Mutable Strings in a modern language you ought to know what you are getting into. Treating blocks of allocated memory as blocks of memory rather than what they represent is not an abstraction.

Yes, but making a mutable string thread-safe is trivial. Just have the compiler enforce reference counting with copy-on-write semantics, and make sure that it uses atomic increments and decrements for the reference counting, and the problem is gone. This is something the compiler should be able to handle; the user shouldn't have to worry about it at all.

You know what used Reference counting? Visual Basic 6 and COM. You know what was a giant pain in the ass to work with in Visual Basic 6, and COM in particular? Strings. Of course in that instance there was no reference counting of strings, they were just BSTR's. But wouldn't having reference counting imply it is a reference type? I thought you were arguing against it being an object at all, but your method of implementing a thread-safe strings requires that it be an object? You can't rightly "reference count" a block of memory. And it would be rather hefty to insert copy on write semantics into what is otherwise a completely arbitrary block of memory. Why would strings get copy n write semantics and not arrays of floats, for example?

A better question, is what real advantages does having a mutable string really provide, anyway? I would argue that they wouldn't be worth the trouble. The only one I can see is it for performance, while performing a lot of concatenations. That hardly seems worth the effort, particularly since you can just use a StringBuilder. How would interning work with these mutable strings? Would there be interning at all?

Strings as Null:

Strings are class/reference types so in that regard it would be silly for you not to be able to make them null. But forgetting that...

What is a string in Delphi? is it not basically an "array of char" (with the actual type char depending on the string type, which you of course have to decide for yourself and cannot choose at run-time, as far as I can tell)? The compiler inserts all the fancy fun stuff for handling operators, comparisons, etc, but as a primitive type it is simply an array of characters, just like in C; but of course a hell of a lot easier to deal with.

Thing is- you can set an array of char to nil, so why not a string? What inherent property of strings, as implemented in Delphi, makes them "more" than just a array of chars?

Basically you are arguing that strings shouldn't be objects and should be mutable, like an array. But that the language/compiler should make it so this array, unlike any others, cannot be set to nil/null. But why? an array of char with zero elements is different from an array of char that is nil, is it not? And, a string, being fundamentally an array of char ought to posess the same qualities as that array, including nullability.This was something of an issue I had with VB6. It's strings were always BSTR's; but a BSTR variable can be set to null. You can set a VB6 string to null using vbNullString,but why is a vbNullString counted as equal to vbEmptyString and ""? vbNullString is a null BSTR pointer, vbEmptyString is some random empty string allocated when the runtime starts, and "" is allocated when you use it... they count as equivalent because the language designers decided "hey, you know how vbNullString, vbEmptyString, and "" are all totally different? Let's make it so they compare equal", probably because they were drunk. Hell if I was responsible for VB6 I might have been a heavy drinker as well.

The problem is, that might make 60 or 80% of tasks dealing with strings a little easier, but it makes that upper 40-20% a gigantic pain in the ass, requiring you read a book with an entire fucking chapter devoted to vbNullString, vbEmptyString, and "" and how they are different but still somehow the same, in the name of "abstraction". You also complained that you couldn't get beneath the abstractions of the CLR; well, for one, you can, as evidenced by being able to change the Empty String constant using reflection, and secondly, a good abstraction wouldn't need to be "gotten under" anyway, since if you need to go beneath an abstraction it's because that abstraction doesn't implement something or provide a way for you to change what it abstracts in a way you want. Besides, you can hook into all sorts of CLR events from both unmanaged as well as managed code; at least you used to be able to, I haven't had to do it in any actual application because the abstractions provided abhorred the necessity to get beneath them.

@Zecc said:

Only to be greeted with an Add-ons Manager without those add-ons listed. Where the hell have they gone?

Not that you care, but it was partly my fault for leaving the new .xpi with a different filename extension. Apparently FF spazzed out when it encountered that file in the extensions directory and decided not to parse the rest of the extensions. *sigh*

Oh, apparently my little hack of the other extension's install.rdf file didn't work. FF decided to erase the hacked .xpi from the extensions directory without the least manifestation. Thanks again Mozilla!

boomzilla

@Zecc said:

Sorry for the ~~off~~ on-topic post, but coming back to the subject of Mozilla's nonsensical behavior of late, I have just been greeted with Firefox being updated to version 5.0 even though I distinctly recall having told it repeatedly that I did not want it to update just yet.

Firstly, FTFY.

I believe that with the new versioning system, the major version number isn't really what it used to be, and so they won't even be providing security updates for earlier major versions, starting with 4.0. I think 3.6 still does.

@boomzilla said:

@Zecc said:
Sorry for the ~~off~~ on-topic post
Firstly, FTFY.

I was being sarcastic, but you probably knew that.@boomzilla said:

I believe that with the new versioning system, the major version number isn't really what it used to be, and so they won't even be providing security updates for earlier major versions, starting with 4.0. I think 3.6 still does.

I figured this much. But what really annoys me is that they updated behind my back.

Well okay, what really annoys me wasn't the update, but the consequences of the version number change. I was forced to take action to fix things that weren't broken despite not having done anything to provoke this situation.

boomzilla

@Zecc said:

@boomzilla said:
@Zecc said:
Sorry for the ~~off~~ on-topic post
Firstly, FTFY.

I was being sarcastic, but you probably knew that.

Yeah, I just wanted to belabor that point. :-)

@Zecc said:

I figured this much. But what really annoys me is that they updated behind my back.
Well okay, what really annoys me wasn't the update, but the consequences of the version number change. I was forced to take action to fix things that weren't broken despite not having done anything to provoke this situation.

Yeah. In principle, I think the quicker releases and more incremental feature implementation is a good thing, but the quick version changes don't work well with their addon compatibility system. At the minimum, they need something in the interface that the user can click to say, "I know this isn't officially supported, but just do it." The biggest, most popular addons (e.g., firebug, noscript) will probably be able to keep up with the version stuff, but it's going to be a major pain, especially if the version bump happens every few months.

@boomzilla said:

I believe that with the new versioning system, the major version number isn't really what it used to be, and so they won't even be providing security updates for earlier major versions, starting with 4.0. I think 3.6 still does.

Correct. According to one of the Mozilla geniuses, there will be no security updates to any older versions of Firefox, beginning with Firefox 4. Firefox 5 is the update for Firefox 4. Firefox 6 is the update for Firefox 5 .......... and so on. If Mozilla stays to their planned schedule it means that beginning with Firefox 4, if your copy of Firefox is more than 3 months old it is no longer supported. And they want to eventually cut it down from 3 months to 6 weeks. Maybe if they release a new major version every week they will eventually pass all the other browsers and have the biggest, bestest and newerest verison number.

Recently, Jay Sulivan, Mozilla VP of Products, has done some half-hearted backpedalling. @Jay Sullivan said:

"A key challenge for enterprises is that they need to certify their websites, apps and add-ons each time Firefox is updated. This can take weeks or months. Security is also paramount, enterprises need access to a version that includes all known security fixes.
We are exploring solutions that balance these needs, with active discussion in our community. "

No mention of the bugs that were filed 7 years ago asking for .msi installer and Group Policy support and still remain open and ignored. Where I work, that's known as FOAD (Fuck Off And Die).

Weng

@El_Heffe said:

No mention of the bugs that were filed 7 years ago asking for .msi installer and Group Policy support and still remain open and ignored. Where I work, that's known as FOAD (Fuck Off And Die).

I'm periodically tempted to learn some fucking C++ and maintain a Firefox fork that's actually sane - and then I remember that I'd have to keep up with this stupid-assed "release cadence" and forget about it.

@boomzilla said:

the quick version changes don't work well with their addon compatibility system.

Extensions are one of the things that made Firefox enormously popular in the first place and breaking them every couple months will result in a shitstorm of bad PR headed Mozllia's way. @boomzilla said:

At the minimum, they need something in the interface that the user can click to say, "I know this isn't officially supported, but just do it."

The problem is, it isn't always that simple. As I mentioned in an earlier post, the author of one of the extensions I use had to modify the code in his extension twice in one month due to changes made to Firefox. How many people are using extensions that are not maintained that diligently? A lot.

This will not end well.

The way they are doing it is just plain silly. Not so much that they are incrementing the major version regardless of whether there are any major changes, but the fact that they are dropping support for older versions. Even if the product is free/Open Source, you are still alienating users who prefer the previous version for one reason or another. If Microsoft did this with Internet Explorer and completely dropped support for IE 7 when IE8 was released, and IE8 when IE9 was released, they would never hear the end of it.

At this point, I have to agree with whomever said basically that browsers are a "solved problem" in that there isn't much to add in the way of features. Most of the stuff that can be added, and often is, to browsers are either something that can be easily added via an add-in (that's why they are called "add-ins" after all) or they are just pointless eye candy with no true functional advantage. If anything it would make more sense to not increment the major version, but still focus on the things they are now, which from the looks of the FF5 changelog is well rooted in the area of supporting more draft standards, that way the W3C will know what to rename the released standards for them to.

boomzilla

@El_Heffe said:

@boomzilla said:
At the minimum, they need something in the interface that the user can click to say, "I know this isn't officially supported, but just do it."

The problem is, it isn't always that simple. As I mentioned in an earlier post, the author of one of the extensions I use had to modify the code in his extension twice in one month due to changes made to Firefox. How many people are using extensions that are not maintained that diligently?

Yes, hence "at the minimum." I've never written extensions for FF, but I've manually edited the "compatible with" information, too. It would at least give you a chance to try. Of course, when it breaks...

PJH

@boomzilla said:

@El_Heffe said:
@boomzilla said:
At the minimum, they need something in the interface that the user can click to say, "I know this isn't officially supported, but just do it."

The problem is, it isn't always that simple. As I mentioned in an earlier post, the author of one of the extensions I use had to modify the code in his extension twice in one month due to changes made to Firefox. How many people are using extensions that are not maintained that diligently?

Yes, hence "at the minimum." I've never written extensions for FF, but I've manually edited the "compatible with" information, too. It would at least give you a chance to try. Of course, when it breaks...

You both know that it's possible for Firefox to be told to not bother with the compatibility check? OK, it's not there by default, but it is there if that sort of thing matters to you.

boomzilla

@PJH said:

You both know that it's possible for Firefox to be told to not bother with the compatibility check? OK, it's not there by default, but it is there if that sort of thing matters to you.

No, I wasn't aware of that. Thanks. Following a link from the nightly addon, the add on compatibility reporter looks like it might be enough. And it's by Mozilla. I don't really care that much (which might be partly why I've never found this stuff), since I rarely use FF these days. I just enjoy piling on WTFs.

@boomzilla said:

In principle, I think the quicker releases and more incremental feature implementation is a good thing

I don't think anyone disagrees that "quicker releases and more incremental feature implementation is a good thing". But this has nothing to do with the change from a system where version numbers had a decent granularity and provided some idea of the progress between application versions, to a system where basically there are only major version numbers. I believe I'm stating the obvious here.

boomzilla

@Zecc said:

I don't think anyone disagrees that "quicker releases and more incremental feature implementation is a good thing". But this has nothing to do with the change from a system where version numbers had a decent granularity and provided some idea of the progress between application versions, to a system where basically there are only major version numbers. I believe I'm stating the obvious here.

No, there are quite a few people not interested in quicker releases (security patches excepted). That's what the mozilla guy was talking about with respect to enterprise users. Even though there may not be very much changed, it can be a lot of work for those people to verify that the new version won't break something critical.

powerlord

@fatbull said:

@blakeyrat said:
add-ins break on every single release
The solution is obvious: Authors need to specify add-in meta data a more carefully. All they really need to do is change <maxVersion>3.1.*</maxVersion> to <maxVersion>27.2a1</maxVersion> (since 27.2 alpha 2 will break the add-in). That's not rocket science; it merely requires a little forethought.

Congratulations, Mozilla has rejected your extension from the official addon site for having a maxVersion higher than 7 (which is the latest announced version). Which is all of 6 months down the line.

And yes, this is documented on the Mozilla Plugin Authoring site, but I'm too lazy to go search for the right page on their site.

powerlord

@blakeyrat said:

@Mason Wheeler said:
I assume you're thinking of the XBox 360 controller, which is halfway decent, though I wouldn't agree that it's better-designed or more comfortable than the PlayStation's DualShock.

The DualShock isn't bad, but look where the thumbsticks are and try to correlate that with the position of your actual thumbs while holding the thing. Whoever designed the DualShock obviously thought that symmetry was more important than comfort. Comfort aside, the thing's labelled with shapes instead of letters. That's retarded. Even technologically, the 360's "all-analog" approach is better than Sony's "mostly digital" approach. Analog face buttons FTW. Oh, and it can be used on a PC.

The DualShock 2 shipped
at the PS2's launch in 2000. The four symbol buttons on the on the right side of
the controller have analog sensitivity. The first game to really use this feature was 2001's Metal Gear Solid 2: Sons of Liberty. I believe the Sixaxis and
Dualshock 3 controllers extend analog controls to the four triggers. In other words, the PS2 had analog buttons before the Xbox (original) even came out in 2001. I guess we know which console you had in the 2000s.

Also, the
thumb sticks were designed for your convex thumbs to fit into the
concave areas on the stick top, rather than pushing the sticks from the
side.

@boomzilla said:

No, there are quite a few people not interested in quicker releases (security patches excepted). That's what the mozilla guy was talking about with respect to enterprise users. Even though there may not be very much changed, it can be a lot of work for those people to verify that the new version won't break something critical.

You are right, of course.

But I don't think there's anything wrong with quicker releases as long as on the one hand they don't shove them down your throat*, and on the other they provide version names that help distinguish security patches from internal API updates from major UI changes.

* Unbeknownst to me, after I installed FF4 it decided to set its updates to "automatically download and install". I've now changed it back to "ask me what to do

boomzilla

@Zecc said:

* Unbeknownst to me, after I installed FF4 it decided to set its updates to "automatically download and install". I've now changed it back to "ask me what to do

Well, for security purposes, that's actually the sane option, since the older versions won't be getting any security updates. And that may be TRWTF from a user's perspective. Obviously, it makes the maintainers' lives easier.

blakeyrat

Aw, we're talking Firefox again, now Wheeler's never going to answer the simple question he dodged all day yesterday.

Sutherlands

@blakeyrat said:

Aw, we're talking Firefox again, now Wheeler's never going to answer the simple question he dodged all day yesterday.

I think that's probably a good thing. This trolling was getting tiring.

C_Octothorpe

@Sutherlands said:

@blakeyrat said:
Aw, we're talking Firefox again, now Wheeler's never going to answer the simple question he dodged all day yesterday.
I think that's probably a good thing. This trolling was getting tiring.

I was really hoping that he had a valid reason for thinking that '' == NULL, like it was going to me a moment of clarity or something.

zipfruder

I like firefox, but this rapid release schedual is bringing back the browser wars, this time being a race to see who finishes implementing HTML5 and friends, and mozilla might be on the loosing side again.

@blakeyrat said:

Aw, we're talking Firefox again, now Wheeler's never going to answer the simple question he dodged all day yesterday.

What question? This question?

@blakeyrat said:

Explain what is wrong with the runtime, everything-as-objects and managed code.

This is a triple question:

What's wrong with the runtime
What's wrong with everything-as-objects
What's wrong with managed code?

I admit I'm somewhat wishful for any of those to be answered.

BTW, I never thanked you for reminding me that you can click thumbnails when alt+tabbing. I've done this a few times since you've mentioned it.

blakeyrat

@Zecc said:

@blakeyrat said:
Aw, we're talking Firefox again, now Wheeler's never going to answer the simple question he dodged all day yesterday.
What question? This question?

No, the specific question he was dodging was this:

@Sutherlands said:

@Wheeler and the Power of FIRE! said:
and the .NET framework it's based upon creates several baseline abstractions that you can't get beneath.
Example?

Sutherlands asked for a specific example of a .net abstraction you "can't get beneath." Wheeler spent about 50 times more effort dodging the question than it would have taken to actually provide an example, if he had one, which he obviously didn't, because he's a douche.

The only reason I care if he answers the question, because I think it's hilarious that:
1) he painted himself in a corner, by bringing up a point he couldn't defend at all
2) he thinks people on this board are dumb enough to just kind of forget the question was asked, if he dodges it long enough

Re: alt-tab click, yeah, that's a lifesaver, I use it at least a dozen times a day.

ender

@powerlord said:

I believe the Sixaxis and
Dualshock 3 controllers extend analog controls to the four triggers.

All buttons (except for Select/Start) were already analog on DualShock 2. SixAxis/DualShock 3 just changed the L2/R2 into actual triggers.

Sutherlands

@C-Octothorpe said:

I was really hoping that he had a valid reason for thinking that '' == NULL, like it was going to me a moment of clarity or something.

Yeah, I'm really interested in finding out new things... Eric Lippert's blog is awesome for that. But... that just didn't happen in this thread.

zipfruder

@C-Octothorpe said:

I was really hoping that he had a valid reason for thinking that '' == NULL, like it was going to me a moment of clarity or something.

well pascal strings had the first byte of the string array as the length, ergo an empty string would be an a byte array of length 1 whose only value would be... null. The more complex strings types in delphi are null terminated strings with a reference count and length tacked on at the begining(yeah ponder that) and a pointer to the first character; an empty string in that case is a null pointer.

Sutherlands

@Mason Wheeler said:

And actually, it's a static method that doesn't have a this parameter. And I know exactly what extension methods are.

The first statement is not true. And by extension (pun intended) I don't think the second one is either.

Sir_Twist

@boomzilla said:

At the minimum, they need something in the interface that the user can click to say, "I know this isn't officially supported, but just do it."

[url=https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter]Add-on Compatibility Reporter[/url]

HTH, HAND.

Mason_Wheeler

@blakeyrat said:

@Zecc said:
@blakeyrat said:
Aw, we're talking Firefox again, now Wheeler's never going to answer the simple question he dodged all day yesterday.
What question? This question?

No, the specific question he was dodging was this:

@Sutherlands said:
and the .NET framework it's based upon creates several baseline abstractions that you can't get beneath.
Example?

Sutherlands asked for a specific example of a .net abstraction you "can't get beneath." Wheeler spent about 50 times more effort dodging the question than it would have taken to actually provide an example, if he had one, which he obviously didn't, because he's a douche.

The only reason I care if he answers the question, because I think it's hilarious that:
1) he painted himself in a corner, by bringing up a point he couldn't defend at all
2) he thinks people on this board are dumb enough to just kind of forget the question was asked, if he dodges it long enough

Well, I definitely think you're dumb enough to just kind of forget that I answered the question. I stopped responding to all the ridiculous "LOLOL! YOU DIDN'T ANSWER TEH QUESTIONZ DERP DERP!" nonsense because it was pointless. As I pointed out repeatedly, if you don't understand the answers I gave, that does not mean that I didn't give one; it means you have no understanding of the fundamental principles of software engineering. That is not my fault and I will not be held responsible for it.

Mason_Wheeler

@C-Octothorpe said:

@Sutherlands said:

@blakeyrat said:
Aw, we're talking Firefox again, now Wheeler's never going to answer the simple question he dodged all day yesterday.
I think that's probably a good thing. This trolling was getting tiring.

I was really hoping that he had a valid reason for thinking that '' == NULL, like it was going to me a moment of clarity or something.

My reason, as I explained multiple times, is that there's no difference in meaning between an absent string (which contains no information) and a empty string (which contains no information.) Honestly, how difficult is this to understand?

The counterclaim seems to be "this is very bad because it causes all sorts of trouble on Oracle databases." But that really has nothing to do with the issue under discussion. All that means is that Oracle implemented their equality check in a very sloppy way. There's still no difference in meaning between a string which contains no information and a string which contains no information.

C_Octothorpe

@Mason Wheeler said:

There's still no difference in meaning between a string which contains no information and no string at all.

FTFY

Not that I want to rehash an argument, but I disagree. You can look at this was (a bit of a stretch, but nonetheless): does 0[zero] == NULL?

It muddles the database and changes the meaning of your data, IMO.

Personally, I think this is a matter of you've been using Oracle for so damn long that you're just used to it's warts, and that's fine. We'll just have to agree to disagree.

blakeyrat

@Mason Wheeler said:

Well, I definitely think you're dumb enough to just kind of forget that I answered the question. I stopped responding to all the ridiculous "LOLOL! YOU DIDN'T ANSWER TEH QUESTIONZ DERP DERP!" nonsense because it was pointless. As I pointed out repeatedly, if you don't understand the answers I gave, that does not mean that I didn't give one; it means you have no understanding of the fundamental principles of software engineering. That is not my fault and I will not be held responsible for it.

You didn't give any answers to understand, my understanding of the fundamental principles of software engineering aside.

I'm saying you didn't answer the question because you didn't answer the question. Not because you answered it and I didn't understand it. Scroll up. Re-read. Maybe you're confused.

delta5341

He expects us to have this "fundamental principles of software engineering" as if we were software engineers. On a personal note I'm still in college and am going down the computer science route.

Mason_Wheeler

@C-Octothorpe said:

@Mason Wheeler said:
There's still no difference in meaning between a string which contains no information and no string at all.

FTFY
Not that I want to rehash an argument, but I disagree. You can look at this was (a bit of a stretch, but nonetheless): does 0[zero] == NULL?

What exactly is 0[zero]? If I read that as parenthesis instead of square brackets, (as an explanation instead of some bizarre array subscript?) then yes, it's commonly accepted that a pointer with a value of 0 is the definition of a null pointer. What does that have to do with strings? (Or did you mean something different and I'm misreading it? That's entirely possible.)

It muddles the database and changes the meaning of your data, IMO.

What is the change? No one has provided any explanation for that that isn't logically reducible to a simple rehash of the technical explanation for nullable values, which is irrelevant. I asked about meaning, not technical implementation details. If there's a real difference in the meaning (to the user, not the programmer) between a null string and a non-null empty string, then what is that difference?

Personally, I think this is a matter of you've been using Oracle for so damn long that you're just used to it's warts, and that's fine. We'll just have to agree to disagree.

Actually no, I've never used an Oracle database. I didn't even know that that's how it represents strings until yesterday when someone on here started making a big issue out of it and told me to go look at that other forum about Oracale DBs. I use Firebird (and occasionally MySQL) for personal projects and MS SQL Server at work.