Replies: 9 comments 22 replies
-
|
Just making sure: is /usr/local/share/haxe the nightly version? Or do you have two Haxe installs? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, |
Beta Was this translation helpful? Give feedback.
-
Display.hx and Protocol.hx are part of the Haxe standard library. If the Haxe nightly compiler is producing errors in its own standard library, that seems like a bigger issue, and I personally wouldn't trust any errors it reports about Lime until that issue is resolved. |
Beta Was this translation helpful? Give feedback.
-
|
It's a nightly build....I'm going to go out on a limb here and say that this has nothing to do with lime. There are errors here in the haxe standard library. Lets avoid writing issue reports for compatibility with unofficial versions of haxe. I suggest we close this... |
Beta Was this translation helpful? Give feedback.
-
|
If Lime's errors were reported first, I might be worried. But since they come after a slew of standard library errors, there's a good chance they'll go away when those are fixed. |
Beta Was this translation helpful? Give feedback.
-
|
Well, just as a rule of thumb... it's better not to jump to conclusions about compatibility with a development build of Haxe. If anything, bring an issue up over at the Haxe git in regards to this. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
No, that's not quite the point of an abstract. In actuality, an abstract is a type definition that provides a common interface for a set of related types. The purpose of an abstract is to abstract away the specific details of each related type and provide a common interface that can be used to interact with any of the related types. This enables polymorphism. I mean, the documentation is quite literal in this definition. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so the confusion is the words "same" and "different." The Haxe documentation says "different" because they mean "different from the abstract type." I said "same" because I meant "the same as the underlying type." Either wording works, but I guess you gotta clarify.
That's an interface or abstract class, not an abstract. Isn't it great that Haxe named two unrelated language features nearly identical names? |
Beta Was this translation helpful? Give feedback.
-
Another way to think about it: if the underlying type qualifies as a constant value, the abstract type does too. So you can define new constant values by abstracting old ones. |
Beta Was this translation helpful? Give feedback.
-
Both abstracts and interfaces provide a mechanism for achieving polymorphism, but they work in slightly different ways... As I'm sure we both know, an interface is a contract that a class can choose to implement. It defines a set of methods, fields, and properties that the class must implement. Conversely, Abstracts in Haxe enable us sort of an abstract polymorphism. I wrote an example, which you can test here: https://try.haxe.org/#2Cb8C87C @:forward
abstract Person(String) to String {
public var name(get, set):String;
public var surname(get, set):String;
public var age(get, set):Int;
public function new(name:String, surname:String, age:Int) {
this = name + "::" + surname + "::" + Std.string(age);
}
public inline function get_name():String {
return __split(this)[0];
}
public inline function set_name(value:String):String {
return this = __modify(this, 0, value);
}
public inline function get_surname():String {
return __split(this)[1];
}
public inline function set_surname(value:String):String {
this = __modify(this, 1, value);
return value;
}
public inline function get_age():Int {
return Std.parseInt(__split(this)[2]);
}
public inline function set_age(value:Int):Int {
this = __modify(this, 2, Std.string(value));
return value;
}
@:to
private inline function toObject():Dynamic {
var s:String = this;
var arr:Array<String> = s.split("::");
return {name: arr[0], surname: arr[1], age: arr[2]};
}
private static function __split(s:String):Array<String> {
return s.split("::");
}
private static function __modify(s:String, index:Int, x:String):String {
var arr:Array<String> = __split(s);
arr[index] = x;
return arr.join("::");
}
}Yes, it's true that the underlying definition is a String, but we've outlined new variables as well. At runtime, it is no longer a String but a Person Type, complete with a unique constructor, and it's own fields. Not only that, it can behave as a String or an Object with definitions for its implicit transition to an Object. Here is the output from tracing out it's unique fields, as a String, and as an Object from the try.haxe example: |
Beta Was this translation helpful? Give feedback.
-
|
Not only that, but an Abstract can use an Interface as its underlying Type in order to provide powerful inheritance based architecture for Anonymous Structures like this: @:forward
@:transitive
abstract LoginMessage(Message<ILoginMessage>) from ILoginMessage
{
public static inline var LOGIN_STATUS:MessageType<ILoginMessage> = "loginStatus";
public inline function new(){
this = new Message<ILoginMessage>();
this.data = new Object();
}
}
@:forward
@:transitive
abstract Message<T>(T) from T to T to Object
{
public inline function new(){
this = new Object();
}
}
interface ILoginMessage extends IDataMessage<ILoginData>
{
}
interface ILoginData
{
var username:String;
var password:String;
}
interface IDataMessage<T> extends IMessage
{
public var data:T;
}
interface IMessage
{
public var type:String;
public var connection(default, null):Connection;
} |
Beta Was this translation helpful? Give feedback.
-
|
Ok, nvm, I guess it makes sense if the Abstract is fully resolvable at compile-time. That's actually not that head-spinning. It has nothing to do with the underlying type per se, only that it can be completely resolved during compilation. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I tend to get twisted up on these things sometimes. My curiosity is really bugging me so I filed an issue: HaxeFoundation/haxe#11005 (comment)
Yeah it could be, if you knew what the value was before runtime. I guess my point there was that the underlying String value didn't necessarily make it eligible to be a constant. The age, name, and surname fields could be read only, but in this case they're read/write, disqualifying it from being one. Anyway, nice discussion. 🤣 |
Beta Was this translation helpful? Give feedback.
-
It actually compiles as long as you don't try to set those values. And if you do try it prints an error message specific to this exact situation. Which makes me think "abstracts as constants" are intended and have been around for some time. Edit: Actually, you also need to inline the constructor. Then it'll compile. |
Beta Was this translation helpful? Give feedback.
-
Yeah, obviously they have been, since core types like UInt are abstract. It still seems a bit weird to me personally, although I wonder if they changed the way this behaves due to the errors noted before. On a side note I don't believe final and inline quite do the same thing at the moment irrc in tests looking at certain use cases in transpiled code. Often they do the same thing, but sometimes they don't, unless there have been changes in recent versions I'm unaware of. Here are a few differences I noticed: When accessing the value from different modules: If you declare a static final value in one module and access it from another module, the value will be accessed via a function call at runtime. On the other hand, if you use static inline, the value will be inlined and accessed directly, resulting in faster execution. When the value is used in a loop: If you use a static final value in a loop, it will be accessed via a function call on each iteration, which can lead to a performance overhead. However, if you use static inline, the value will be inlined and accessed directly, resulting in faster execution. When the value is used in an expression: If you use a static final value in an expression, it may not be inlined by the Haxe compiler, depending on the context. However, if you use static inline, the value will be inlined, resulting in faster execution. |
Beta Was this translation helpful? Give feedback.
-
They don't, and I didn't mean to imply otherwise. In my comment above, I was talking about I distinctly recall mentioning the fact that |
Beta Was this translation helpful? Give feedback.
-
Oh, I was actually just reflecting on my own thoughts. It was a little confusing at one time a while ago. |
Beta Was this translation helpful? Give feedback.
-
|
Removing |
Beta Was this translation helpful? Give feedback.
-
Yeah precisely. It's pretty counter intuitive to get an error about inlines when using a macro to remove inlines. 🤣 |
Beta Was this translation helpful? Give feedback.
-
Awesome, thanks for confirming that this is indeed a haxe bug! Proud to have so many intelligent and capable developers involved in the Lime ecosystem ❤️. On that note, what do you all think the impact on the lime toolchain is if we just remove it anyway? Are we inlining much to begin with? |
Beta Was this translation helpful? Give feedback.
-
|
Testing reveals that While this is technically a compiler bug it's probably best to remove the flag anyway, since it could lead to other issues in the future (given that it's clearly not tested very well). |
Beta Was this translation helpful? Give feedback.
-
Since |
Beta Was this translation helpful? Give feedback.
-
|
Well, I think the consensus is that we aren't supporting 3.2.1 anymore. At some point its fair to stop supporting Haxe 3 all together...although that is entirely a topic for a totally different discussion. Anyways, I think @Apprentice-Alchemist is right so we should just go ahead and remove it. |
Beta Was this translation helpful? Give feedback.
-
Using the develop branch:
Runs with no issues on 4.2.5. Could be related to #1373?
Beta Was this translation helpful? Give feedback.
All reactions