2
$\begingroup$

Considering how often we do:

variable = variable + another;
variable = variable - another;
variable = variable * another;
variable = variable / another;
variable = variable & another;
variable = variable | another;
variable = variable ^ another;

we then made the following language shortcuts:

variable += another;
variable -= another;
variable *= another;
variable /= another;
variable &= another;
variable |= another;
variable ^= another;

so, then, considering how often we do this:

variable = variable.different();
// or variable = variable->different();
// or variable = variable::different();

(for instance, stringVar = stringVar.toUpperCase()), why isn't there one of these?

variable .= different();
// or variable ->= different();
// or variable ::= different();

is it a parsing issue? Would it be too hard? Or is there some obvious thing I don't see here?

I'm not asking for opinions, here. I want to know if there's any documented, historic, technical, or other verifiable reasons for why there is no such operator.

$\endgroup$
  • 3
    $\begingroup$ This looks pretty subjective. What kind of answer do you expect? It might just have been an arbitrary decision made by language designers, for all I know. We look for questions that will attract answers that can be supported with facts, references, and evidence, and that can be judged objectively based upon evaluation criteria specified in the question. Maybe if you narrow it down to just asking about parsing... As far as your question: Have you done any quantitative research? How often does variable = variable.different(); appear in code? $\endgroup$ – D.W. Aug 2 '14 at 1:19
  • 2
    $\begingroup$ @D.W. And is it so often that replacing it with variable.set_different() would make more sense? (If different() is only used for updating the calling object, then using the assignment operator may not be the best syntax anyway.) $\endgroup$ – Paul A. Clayton Aug 2 '14 at 2:18
  • 1
    $\begingroup$ @Supuhstar, I was asking if you've measured how often x = x.m() occurs in code, compared to x = x + y / x += y. It's possible that language designers thought x = x.m() would be rare. In C, I would expect it is rare. But your example helps -- it suggests that this probably applies only to immutable types; for mutable types, we'd be more likely to use a different idiom, as Paul Clayton mentions. For instance, maybe the designers of C figured it'd be rare, and the other languages just copied from C. But this is speculation; I don't know how we'd ever get evidence. $\endgroup$ – D.W. Aug 2 '14 at 5:34
  • 2
    $\begingroup$ What language are you talking about? $\endgroup$ – Gilles Aug 2 '14 at 8:47
  • 1
    $\begingroup$ I think that in some languages (e.g. Scala) creating such syntax (i.e. methods called like operators that look like syntax) is possible. $\endgroup$ – Raphael Aug 2 '14 at 10:45
3
$\begingroup$

In the situtation: variable += another; you have 2 variables, 1 operator and 1 assignment.

In the situtation: variable ->= different() you have 1 variable, 1 method access operator ( i.e ->), 1 method name that needs to be called and 1 assignment.

When a language's syntactic sugar feature is designed, one important concept to consider is composition, i.e how elegantly you can compose these syntactic sugar based expressions.

In the first example you can create a chain of these operations:

variable *= another_var -= variable += another;

Whereas there is no simple way to do this kind of composition in the second case. Lets say we have the below code:

variable = variable.method1();
another_var = variable.method2(params);

If you try to apply the approach that you suggested, you will get into weird situtation:

another_var .= <what should be here> variable .= method1()

In the method based case there is pattern called "fluent API design". You can use that to express the above code elegantly.

another_var = variable.method1().method2(params);

Hope this helps.

$\endgroup$
  • $\begingroup$ your example with chaining is good, but wouldn't that also break down if the first or any middle variable was actually a constant? $\endgroup$ – Supuhstar Aug 3 '14 at 1:20
  • $\begingroup$ Any attempt at assignment to a constant would fail (after initialization). If you want to use a constant, don't try assigning to it, that's not what constants are for. $\endgroup$ – ZeroUltimax Aug 3 '14 at 13:15
2
$\begingroup$

The simple thing is we rarely found this situation for using like this

 variable = variable.different();
// or variable = variable->different();
// or variable = variable::different();

since we call a function with objects and assign the return value to the variable and normally we never return an object back to the same in old days.

there fore the compiler designer will never think about giving special meaning to the .= or ->=

but if you take the examples of arithmetic operators we will found this may be in every program like tormenting adding etc .

but when the concept of OOP is increased rapidly one need to think about giving such a special meaning..

$\endgroup$
2
$\begingroup$

IMO, the biggest reason is that identifiers are not first class values in programming languages and "." is not a real operator like + or - are. For example, you can't convert

var foo = variable.bar()

into

var name = bar
var foo = variable.name()

The same way you can convert

var foo = 1 + 10

into

var x = 10
var foo = 1 + x

In more technical terms, in most languages x + y is an expression, while x, x.y and x[i] are identifiers.

Summing up, when using your hypothetical .=, the right hand side needs to be interpreted as a field name, not an expression. This leads to unintuitive results - the following two lines look very similar but do wildly different things.

x += bar() // calls the bar() global function and add its value to x
y .= bar() // calls y's bar() method, and sets `y` to its result.

Additionally, as Guy Coder pointed out, when using +, -, etc its guaranteed that the type of the resulting expression is the same as the arguments so += always makes sense. On the other hand, we can have y.bar() return a type different from y, in which case .= bar() would make no sense.

$\endgroup$
  • $\begingroup$ Very nice pointing out the difference between expressions and identifiers! I'd forgotten about that entirely! $\endgroup$ – Supuhstar Aug 4 '14 at 2:54
  • 1
    $\begingroup$ Identifiers aren't 1st class citizens in most programming languages. There are ones that do things right. $\endgroup$ – souser12345 Aug 5 '14 at 7:59
  • $\begingroup$ "when using +, -, etc its guaranteed that the type of the resulting expression is the same as the arguments" Not really, at least not in all languages. For example in C#, the result of adding two bytes is an int. Though this results in weird situations, where for example b1 = b1 + b2; doesn't compile, but b1 += b2; does. $\endgroup$ – svick Sep 23 '14 at 2:04
1
$\begingroup$

The reason it is not done is because the type of the result may not be the same as the type of the receiving term.

In the examples you gave the result and receiving terms are the same type or it is common to coerce the type of the result into the receiving term type which is common with mathematical operators.

Standard way
Int = Int + Int

Syntactic sugar
Int += Int

Receiving Term  Other Term  Result  
Int             Int         Int  
Float           Int         Float  
Float           Float       Float  

If it is taken that -> means pointer then you would have

Standard way
Name = Person -> Name

Your way
Person ->= Name

Receiving Term  Other Term  Result  
Object          String      String  

So setting an object to a string would either cause the type of the object to become a string which may not be desired or the compiler might throw an exception.

Standard way
Color = Bird -> Color

Your way
Bird ->= Color

Receiving Term  Other Term  Result
Bird            Color       Color

Obviously a bird should not be a color but can have a color.

$\endgroup$
  • $\begingroup$ I actually meant the "Standard way" to be Color = Color->Bird, and "my way" to be Color ->= Bird $\endgroup$ – Supuhstar Aug 4 '14 at 2:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.