Am I the only one who knows what "strongly-typed" even means anymore???
-
It would stop someone who would steal a cart but doesn't have a dollar.
A lot of these carts get left out in the lot, at which point a person not inclined to even visit can take a cart for nothing.
The money is really just to ensure they're returned to the inside of the store.
But this just all shows that the store doesn't want to pay someone JUST to push carts.
Stores that pay cartpushers, don't seem to have this problem.
I've seen carts which require a coin in plenty of places where you can leave them on designated areas in the parking lot. I suspect (part of) the point is to keep people from leaving the carts in the parking lot in places where cars may run into them.
-
I suspect (part of) the point is to keep people from leaving the carts in the parking lot in places where cars may run into them.
That, and to stop them walking off with the trolleys and taking them home. But then, it didn't really stop that, so now they install brakes that lock a wheel when taken past a certain point as well.
-
But then, it didn't really stop that, so now they install brakes that lock a wheel when taken past a certain point as well.
that's not stopped the issue either.
the brake isn't that hard to break and it won't trip if you lift the cart high enough as it crosses the line.
also it's totes still possible to push the cart with one wheel locked.
-
Just a thought, folks.
PHP treats strings as strings for type purposes. You can't add to a string.
You know it's fucked up when PHP gets it right and <insert language here> doesn't.
-
You can't add to a string.
But you can concatenate two strings, and that's a pretty common overload. It even has almost the right sort of semantics, with the empty string acting as a “zero”. (It's not commutative, but many algebraic systems drop that property of add.)
-
Concatenation has a separate operator for a reason - because you still can't add to a string. You can either add something to the end of the collection of bytes that is the string, or you can type-juggle to a number. Both of these are consistent with the rest of PHP's semantics - both are type-coercive operations (whether you type-cast the left or right side of the operator, effectively)
PHP does not under any circumstances randomly pull the kind of shit blakey is talking about. If you want to treat a string/character as a number because of its code point/representation,
ord()is your friend. But PHP won't do it arbitrarily.
-
Hi - don't believe anyone's arguing for wanting access to the implementation detail of a character. However, you're making a dangerously strong statement by asserting there's no reason possible to want to do that.
-
I'm not saying you shouldn't be able to access implementation. Obviously you have to if you want to serialize the data into a file.
I'm saying implementation shouldn't be exposed in an implicit way, especially one that makes a character identical to another type.
You should have to explicitly get the internal implementation.
The best example I can think of is the old CString with MFC. You could get the internal bytes, but you had to call a method to do it.
.c_str()or something similar.
-
I'm not saying you shouldn't be able to access implementation. Obviously you have to if you want to serialize the data into a file.
Why would you need to access the implementation to serialise a string? Just call a method that gets the UTF encoding you need.
-
The UTF encoding is the form of implementation detail I'm talking about.
Serialization is the only time you really need to pull anything out of the class.
Let me change the word I'm using here.
Serialization is the only time you need native data.
You never need direct access to the native data used specifically for implementation of the class.
Those two things can be the same however. For example, old C++ libraries where the implementation of strings was ascii, and the serialization of those strings were also ascii.
It appears that I have to tread carefully to communicate this idea.
-
Strings don't have to be implemented in a UTF; for instance, unless they've changed it, Java uses a format that's like UTF-8, but has a different multi-byte encoding to the UTF-8 standard.
-
Strings don't have to be implemented in a UTF
Serialization is the only time you need native data.
You never need direct access to the native data used specifically for implementation of the class.
Those two things can be the same however.
I'm going to give up at this point, because I personally feel like we're agreeing, but it's just not coming across. Maybe that's not the case, and I'm somehow wrong, but specifically how I'm wrong isn't coming across either.
-
I straight up told you you don't need access to native to serialise a string; if that's not obvious, then I don't know how much clearer I can make it.
-
Well, I don't know what word to use.
The internal native data does not need to be identical to the encoding that the interface offers externally, however, IT CAN BE.
Either way, the only time you need access to a binary representation of the internal data, as encoding, is when you need to serialize.
In no case, ever, ever ever, do you need access to the way the data is represented internally for any operation, ever.
I'm sorry I don't have better words for it.
One day, we may have a time-space distorting machine that represents the string or characters of the string, internally, using pink ponies. But we'll never need to know that.
We'll only ever need to know that when we want to store it on a hard-drive that stores using binary data, we'll need the string in that format, but we won't make good use of trying to store interdimensional pink ponies on a magnetic hard drive. Therefore, it makes no sense to know how the characters are represented internally.
-
Seriously, that's what it's like trying to talk to you sometimes.
If I want to serialise a string, I call a method that gives me a serialised string. At no point do I see the internal implementation. The internal implementation is irrelevant.
Only one person needs access to the internal implementation: the person who implements it. Everyone else uses the API.
-
At no point do I see the internal implementation. The internal implementation is irrelevant.
In no case, ever, ever ever, do you need access to the way the data is represented internally for any operation, ever.
Can you spot the difference?
What you said, is exactly what I meant.
I'm sorry it isn't coming across.
-
Either way, the only time you need access to a binary representation of the internal data, as encoding, is when you need to serialize.
In no case, ever, ever ever, do you need access to the way the data is represented internally for any operation, ever.
Do you not see how these two statements contradict each other?
-
By "a binary representation of the internal data", @xaade does not mean the specific representation that's used internally. He's talking about the representation that's going to be used for serialisation.
-
Wait, what?
Actually, don't bother; no-one's making any fucking sense anymore.
-
Strings don't have to be implemented in a UTF; for instance, unless they've changed it, Java uses a format that's like UTF-8, but has a different multi-byte encoding to the UTF-8 standard.
Just to add more craziness: Java's String is actually UTF-16 but gets serialized as Not-Quite-UTF-8, which is different tostring.getBytes(StandardCharsets.UTF-8)
3 different formats for the price of 1!
-
Flamewar died down while I was away.
So in fact it's completely natural to be able to subtract one character from another.
You're talking about an operation that's defined on a set as if it's defined on the members of the set.
In fact you've assumed some set here but not even defined what it is.
-
And, yes, the common implementation of string concatenation using the addition operator is poor design.
The common implementation of string concatenation is pronounced "concatenate" even when it's spelled "+". You're confusing it with the other "+".
-
Either way, the only time you need access to a binary representation of the internal data, as encoding, is when you need to serialize.
You don't need it even then. Serialization is just another operation that produces a representation as a byte sequence that, when read back in using deserialization, will construct an equivalent structure.
Internal representation is internal. (For example, you could hold both UTF-8 and UTF-32.)
-
You're talking about an operation that's defined on a set as if it's defined on the members of the set.
Unicode is more than just a set, though. As well as specifying which items are to be considered characters, Unicode defines an ordering for them via code points.
This makes Unicode a (huge) alphabet rather than simply a set, so that a natural intepretation of the subtraction operator applied to characters would be to return the alphabetic distance between them according to their positions within that alphabet.
-
-
@xaade said:
Either way, the only time you need access to a binary representation of the internal data, as encoding, is when you need to serialize.
In no case, ever, ever ever, do you need access to the way the data is represented internally for any operation, ever.
Do you not see how these two statements contradict each other?I admit that I cannot. I think the key to my reading is the use of indefinite vs definite articles in talking about binary / native data.
-
So I'm
the only oneone of the few who sees the contradiction betweenTo do A, you need B
and
To do {set of things including A}, you don't need B
-
So I'm the only one who sees the contradiction between
To do A, you need B
and
To do {set of things including A}, you don't need B
No i see it too, however @xaade's second comment that you quoted there reads more like.
There is never any need to do B
which when put into context with the first statement
To do A, you need B
causes me to infer a third statement
(inferred) There is never any need to do A
which in this case causes me to go
-
Right, you don't need it. He's just saying that the closest you come to that is when you serialize. Which doesn't need to be the actual representation (though it could be, who knows or cares?). Which is pretty much what you were saying, just in a different way.
His argument reminded me of a proof by contradiction.
-
the only time you need access to a binary representation of the internal data, as encoding, is when you need to serialize.
I think the only time you need access to a binary representation of the internal data, as encoding, is when you render text or read a keyboard stream. Maybe a few other similar things too.
-
More like
To do A (serialize) you need B (A binary representation, like UTF encoding)
To do {set of things including A (saving to file, or the characters printed out as a font, or painted into a bitmap, or sounded out for text-to-speech) }, you don't need C (THE specific binary representation that is the internal implementation).
B does not equal C, but B may end up being exactly like C. If you had pointers to B and C, the bytes may be exactly the same.... in different memory locations. If B were exactly like C, it would be a separate memory area, so that when you have C and modify it, you don't alter B.
string { Data = 10011101101101110111... } data = string.GetData(); data == 10011101101101110111... // is true // string's data's address in memory is 4235232... // data's address in memory is 63463453... // you cannot alter data, and alter string's Data.So, if I asked for the string as an array of bytes, that may be exactly how it is internally, but it copies it and places the result in another memory location. It never gives me direct access to the internal data.
In the case of C++ with a char being a byte, you can cast that char to a byte, or simply pretend it's a byte and add and int to it. This is total BS and we should never pattern on it.
-
I think the only time you need access to a binary representation of the internal data, as encoding, is when you render text or read a keyboard stream
True true.
But it's hard to say things around here, not because I'm saying it wrong, but the level of pedantry is astronomical.
-
In the case of C++ with a char being a byte, you can cast that char to a byte, or simply pretend it's a byte and add and int to it. This is total BS and we should never pattern on it.
Outside DotNet C++, it seems there isn't even a data type called byte, so we couldn't even pretend a char would be something different. Total BS indeed.
Is there 'byte' data type in C++?
If it exists, is there header file to include? This code results in a compilation error: int main() { byte b = 2; // error }
-
This makes Unicode a (huge) alphabet rather than simply a set
So... a set with some operations defined for it?, so that a natural interpretation of the subtraction operator applied to characters would be to return the alphabetic distance between them according to their positions within that alphabet.
How so? The operator alphabet_distance would return the distance between unicode chars. That's not character subtraction. Even if you write it '-' it is still "alphabet distance". Calling 'A'.Pos - 'D'.Pos subtraction would make sense but not 'A' - 'C'. (We are trying to make it "strongly typed")
-
Even if you write it '-' it is still "alphabet distance". Calling 'A'.Pos - 'D'.Pos subtraction would make sense but not 'A' - 'C'. (We are trying to make it "strongly typed")
Seconded. In a strongly typed environment,
'A' - 'C'would mean something like
me.house - me.neighbors[2].houseand
'A'.Pos - 'D'.Possomething like
me.house.number - me.neighbors[2].house.number
-
I don't. If @xaade had said "the binary rep" rather than "a binary rep" I would.
-
It's only spelt "concatenate", it's pronounce like "cat". When so pronounced, '+' does indeed remain spelled 'concatenate', but only the second syllable is sounded. Yeesh. Get it right, people.
-
'A'.Pos - 'D'.Pos
It's not impossible to avoid number representations altogether, unless explicitly asked for.
Print(object thing) { Console.WriteLine(string.Format("Type is {0}, Printed value is {1}", thing.GetType(), thing.ToString()); } main() { Print('A' - 'D'); Print((int)('A' - 'D')); } /// output /// Type is CharacterSpan. Printed value is 3. /// Type is int. Printed value is 3. ///
-
Doesn't convince me at all. To me, characters are still members of an alphabet, and have an order, but nothing even remotely similar to an inherent numerical value which would be necessary to sensibly define a character distance.
Or do you mean by a CharacterSpan something like
{'A', 'B', 'C'}or{'A', 'B', 'C', 'D'}(in the case of'A' - 'D')?Maybe depending on the culture (where do you pass that to the difference or character range operator?), so that
'A' - 'D' == {'A', 'Ä', 'B', 'C'}?
A sensible possibility would be to assign numerical values to the letters of the alphabet. E. g. like the ancient Greeks did it, though. But unless explicitly required, I'd stick to positional notation systems. (Which leads to another sensible assignment of numerical values - '0' <-> 0, ..., '9' <-> 9, 'A' <-> 10, ... 'Z' <-> 35)
-
-
Really?
If by 'alphabet' you mean 'an ordering of characters' and not 'literally descended from Greek'.
-
Normally, 'alphabet' means an ordered set of letters. But a lot of Far Eastern scripts don't use letters, instead using logographs and syllabaries, so they don't have alphabets.
-
And that's why there aren't any situations in which any of these things have orders. They're fundamentally unordered, random blobs.
-
@PWolff said:
characters are still members of an alphabet
本気ですか？Sorry, don't know that script system.
I meant alphabet in the sense it is used here:
https://en.wikipedia.org/wiki/Entropy_(information_theory)#b-ary_entropy
'literally descended from Greek'.
The Greek alphabet is related to the Phoenician, and that's related to other, older ones, probably to Egyptian hieroglyphs too.
)
-
Yes, I am aware that 'alpha' and 'beta' are Egyptian words.
-
Wrong again; to take Japanese as an example, it uses four separate writing systems, all of which have ordering systems:
- Romaji: Given this is Latin characters, it uses the Latin alphabet.
- Katakana: Has two orderings, iroha and gojūon
- Hirakana: Has two orderings, iroha and gojūon
- Kanji: Normally ordered by the radical-and-stroke method; other sorting methods exist
-
Sorry, don't know that script system.
It's Japanese; specifically, it's a mix of kanji and hiragana
-
Everything I say is exactly what I mean, all the time. I don't know what sarcasm is. I also know that there are no dictionaries in Japan.
-
Then I suggest you work on making your point clearer
-
Okay, "alphabet" is proably not the word we're looking for. Maybe "set of characters" would be better.
Anyway, if not every set of character has a (unique) ordering, that makes it even more nonsensical to define a "difference" between two characters.
