Sigh.
FWIW this is not new to Xojo
Its existed forever - literally - since day 1 when the product was released 20 years ago (actually even before that as it was this way in the developer releases that went out before version 1.0 was released)
Moving an object is not the same as cloning an object
Java behaves nearly the same when it comes to references being assigned - you get two variables that refer to the same instance
You dont get a COPY of the object - you just get a new reference
And so when you change one it appears to “change the other”
There are numerous languages that do exactly the same
But, since this kind of question comes up repeatedly it’s clear to me that there is a lack of understanding of values types & reference types
[quote=290993:@Norman Palardy]EXPRESSIONS cannot be passed byref
Never have been able to
And anything using a DOT operator is an expression
[/quote]
So then MyModule.kMyConst is treated as an expression?
This sure can’t be passed byRef, of course.
It’s not a “design error” just because other compilers behave in a specific manner.
Nor is it a design error because you say so/
Its been deliberately left in place and left to behave like this since the language was designed 20+ years ago. Quite literally “Forever”.
Claiming that “it must be an error because every other language does X” simply doesn’t fly.
Should every language copy C’s language behaviour “because C does this” ?
No.
Swift deliberately doesn’t in many ways.
Nor does Java.
Thats the whole point of a language is that it is designed to suit particular use cases and may or may not suit EVERY usage.
And they can certainly behave differently even when certain language constructs appear to be similar.
Otherwise why have C, C++, Objective-C, Java, Ruby, python, Perl, PHP, LISP, Haskell, Pascal etc etc etc etc ?
[quote=291026:@Massimo Valle]So then MyModule.kMyConst is treated as an expression?
This sure can’t be passed byRef, of course.[/quote]
Constants are effectively folded to be treated like literal values so no you cant pass a literal byref either
Of course you’re free to try just to confirm what I’ve said
[quote=291028:@Norman Palardy]Constants are effectively folded to be treated like literal values so no you cant pass a literal byref either
Of course you’re free to try just to confirm what I’ve said[/quote]
Right, but the problem here it’s a constant, NOT an expression. So the compiler message is also wrong.
And btw, YOU CAN pass a Module.Property as a byRef argument, but NOT a class instance property.
So far, a Module is like a class with shared properties, and in fact I can pass a Shared Property byRef. The compiler allow this.
So here is something definitely missing.
And IMHO the fact this is missing from day 0 doesn’t qualify it as an “intended behavior”. More like a forgotten implementation…
Module.Property doesnt require a function call so it works.
That you cannot do this, and that it’s existed this way since day 1, and has been reported as a bug previously and not changed is why I say this IS intentional and has remained intentional.
It’s not like we haven’t ever looked at this with an eye to perhaps changing it.
I know we have, and I know it has not changed so it been purposefully left “as is” - hence why I say this IS by design
The details and reasons why I cant say with the same accuracy as Joe might
Sigh.
The root cause of these discussions is that very often a language is treated as a reference and the other language is evaluated by differences with this arbitrary reference.
There are no errors or forgotten features but only different languages.
Many comments about Xojo are clearly based using C++ as a reference implementation where pointers are so much important.
This can be verified reading other threads where people are complaining about how Xojo is seen as a second class citizen only because it “lacks” some feature determined as fundamental but, in effect, it is something fundamental for the other language used as a reference.
Maurizio, I completely disagree on this.
I take no other languages as reference and this is clearly a partial implementation for function arguments by reference.
The fact Norman (as usual) try to sell us the fact this is “by design”, is just disappointing. It would be fairer to say, “We know about this problem and will eventually fix, though it’s not high in priority”.
Additionally, the fact this can be simply workaround using a temporary property, has a part on “leaving it purposefully ‘as is’”.
What I said was this IS by design (and has been by design since day 1).
However if you read my comments from previous posts you’ll also see that I said it seemed plausible to change this.
That other compiler engineers have looked at this and NOT changed the behaviour over the last 10 years suggests its not just “Nah lets leave this as is just so we’re different and to jerk users around” but rather something more fundamental.
Personally I can see the utility of it being changed.
That it hasn’t changed through at least 3 different compiler engineers suggests its not such a simple thing to alter or that there are odd side effects possible or something else - but it hasn’t changed.
[quote=291041:@Norman Palardy]Personally I can see the utility of it being changed.
That it hasn’t changed through at least 3 different compiler engineers suggests its not such a simple thing to alter or that there are odd side effects possible or something else - but it hasn’t changed.[/quote]
This sounds more sensitive to me.
But, at this point, hearing the @Joe Ranieri opinion would be nice.
[quote=291042:@Massimo Valle]This sounds more sensitive to me.
But, at this point, hearing the @Joe Ranieri opinion would be nice.[/quote]
I’d said previously [quote=290108:@Norman Palardy]
Now - COULD the compiler figure out that mycar.oldtires is a value type ?
I suppose thats a good question for Joe - it seems theoretically possible but thats not how it works today.[/quote]
And yet you still responded with
[quote=291035:@Massimo Valle]
The fact Norman (as usual) try to sell us the fact this is “by design”, is just disappointing. [/quote]
That’s disappointing
Welcome to the list
[quote=291031:@Norman Palardy]That you cannot do this, and that it’s existed this way since day 1, and has been reported as a bug previously and not changed is why I say this IS intentional and has remained intentional.
It’s not like we haven’t ever looked at this with an eye to perhaps changing it.
I know we have, and I know it has not changed so it been purposefully left “as is” - hence why I say this IS by design[/quote]
I just mentioned what you said.
And by the way, if you don’t know for sure, let @Joe Ranieri to answer instead of doing suppositions.
I haven’t guessed at why its not changed or why it is the way it is
And I’ve said “I dont know why it hasn’t”
I just know it HAS been looked at by 3 compiler engineers and it HASN’T changed since day 1
Thats why I said
[quote=290108:@Norman Palardy]
Now - COULD the compiler figure out that mycar.oldtires is a value type ?
I suppose thats a good question for Joe - it seems theoretically possible but thats not how it works today.[/quote]
FWIW here’s one CLOSED bug report
<https://xojo.com/issue/2770>
the reply on Jun 3, 2008 at 10:37 AM
[i]
Hello,
Thank you for your submission.
Upon review, the behavior you’re reporting is expected and the software is functioning as designed.
You cannot use an expression when passing a ByRef parameter, and that includes any usage of the dot operator. Only unqualified variables may be used.
If you have further questions regarding the proper usage of this functionality, please feel free to reply to this email.
Thank you,
Aaron Ballman
[/i]
There are others like
<https://xojo.com/issue/3825>
<https://xojo.com/issue/7196>
You see, the funny thing is the above is partially wrong: you CAN use some properties with a dot operator.
Specifically module properties and class shared properties.
ONLY instance properties, you can’t.
As I understand it, such properties are not actually properties (= instance variables) but static variables (“static” meant in C terminology). If Xojo had meta classes, it would probably be different.
I can understand what you mean Eli, however once Xojo make a statement, they should also be precise on what works and what not. Though not necessarily explaining why.
Now, saying that any usage of the dot operator is an expression, it’s clearly wrong and misleading. I said it above and even before regarding constants.
This fact about things working while they say are not and vice-versa, it just makes confusion.
Therefore an explanation would really help everyone understand what can be done, what can’t be done and what to eventually report as a bug or a feature request.