Abstract types & Haxe 3: Practices and proper uses?

[Cambiata]

Hi!

I'm curious about what the practical uses of abstract types can be (http://haxe.org/manual/abstracts), and how it could affect my solutions.
Two examples here:

1.
In my music notation solution, I use "virtual coordinates" for calculation of distances and measurements. These virtual x- and y-coordinates have different "physical" units:
One "virtual x" corresponds to 8 "physical pixels", and one "virtual y" corresponds to 8 "physical pixels".
Today, these virtual coordinates are represented by Float types.
It would be very elegant if these different virtual types could be represented by abstract types, wouldn't it? Let's say:

@:coreType abstract XCoord from Float { }

@:coreType abstract YCoord from Float { }

This way the code would be both safer and easier to read...
Proper use of abstract type?

2.
A file path is a common unit in programming, with some clearly defined attributes: One or many segments separated by predefined types of separators, could start with a physical drive letter etc...
Would it be possible to define a Filepath as an abstract type, in a way that it could itself keep track of it's validity?
Proper use of abstract type?

/ Jonas

[Cambiata]

Sorry, typo:

One "virtual x" corresponds to 4 "physical pixels", and one "virtual y" corresponds to 8 "physical pixels".

[ScrambledRK]

In my experience, abstract reads very similar to interface and both fullfill a similar role. Both are used to define a signature of an object without actually implementing it.

Using an Interface you define all your accessable variables and methodes and the implementation has to implement them all ... or else the compiler screams.

Using abstract you could skip the Interface, just write an ordinary class and define and implement your variables and methodes there but leave some methode bodys empty and type the methodee as abstract. You can now use the object just as you would expect as long as no one calls an abstract methode. If you want to do that, another class has to extend from your (abstract) base-class and implement those abstract methodes. So using abstract makes sense if you have a bunch of code that is everywhere the same, but need to modify punctually a few methodes down the class hierachy and cannot provide a meaningful functionallity in your baseclass for that methode. (it has to be overwritten)

The template pattern makes good use of the abstract keyword. You could get the same result using Interface and composition, or even via inheritance; its just a slightly different approache (favouring inheritance)

[tom rhodes]

very nice explanation, thanks.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haxelang+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Simon Krajewski]

Am 20.02.2013 10:32, schrieb Cambiata:

Hi!

I'm curious about what the practical uses of abstract types can be (http://haxe.org/manual/abstracts), and how it could affect my solutions.
Two examples here:

1.
In my music notation solution, I use "virtual coordinates" for calculation of distances and measurements. These virtual x- and y-coordinates have different "physical" units:
One "virtual x" corresponds to 8 "physical pixels", and one "virtual y" corresponds to 8 "physical pixels".
Today, these virtual coordinates are represented by Float types.
It would be very elegant if these different virtual types could be represented by abstract types, wouldn't it? Let's say:

@:coreType abstract XCoord from Float { }

@:coreType abstract YCoord from Float { }

This way the code would be both safer and easier to read...
Proper use of abstract type?

You should not use @:coreType, but instead define Float as the underlying type:
    abstract XCoord(Float) { ... }
You can then go ahead and allow constrained arithmetic operators, e.g.:
     @:op(A+B) static public function add(lhs:XCoord, rhs:XCoord):XCoord; // no implementation
This allows you to add two XCoord objects, but complains if you try XCoord + YCoord.
You could also define an implicit cast from XCoord to YCoord:
    @:to public inline function toYCoord():YCoord return new YCoord(this * 2);

2.
A file path is a common unit in programming, with some clearly defined attributes: One or many segments separated by predefined types of separators, could start with a physical drive letter etc...
Would it be possible to define a Filepath as an abstract type, in a way that it could itself keep track of it's validity?
Proper use of abstract type?

Sure, why not? You could define a @:to String function which does some checks before emitting the result. The underlying type could be an Array<String>, or something a bit more semantic.

Simon

[Simon Krajewski]

Am 21.02.2013 10:52, schrieb ScrambledRK:
> In my experience, abstract reads very similar to interface and both
> fullfill a similar role. Both are used to define a signature of an
> object without actually implementing it.
>
> Using an Interface you define all your accessable variables and
> methodes and the implementation has to implement them all ... or else
> the compiler screams.
>
> Using abstract you could skip the Interface, just write an ordinary
> class and define and implement your variables and methodes there but
> leave some methode bodys empty and type the methodee as abstract. You
> can now use the object just as you would expect as long as no one
> calls an abstract methode. If you want to do that, another class has
> to extend from your (abstract) base-class and implement those abstract
> methodes. So using abstract makes sense if you have a bunch of code
> that is everywhere the same, but need to modify punctually a few
> methodes down the class hierachy and cannot provide a meaningful
> functionallity in your baseclass for that methode. (it has to be
> overwritten)
>
> The template pattern makes good use of the abstract keyword. You could
> get the same result using Interface and composition, or even via
> inheritance; its just a slightly different approache (favouring
> inheritance)

That's a nice explanation of boring old Java abstract classes, but the
haxe abstract type is something quite different. ;) You can read an
introduction here: http://haxe.org/manual/abstracts

Simon

[tom rhodes]

i spoke too soon :)

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

--- You received this message because you are subscribed to the Google Groups "Haxe" group.

To unsubscribe from this group and stop receiving emails from it, send an email to haxelang+unsubscribe@googlegroups.com.

[Cambiata]

@Simon:

 

You should not use @:coreType, but instead define Float as the underlying type:
    abstract XCoord(Float) { ... }
You can then go ahead and allow constrained arithmetic operators, e.g.:
     @:op(A+B) static public function add(lhs:XCoord, rhs:XCoord):XCoord; // no implementation
This allows you to add two XCoord objects, but complains if you try XCoord + YCoord.
You could also define an implicit cast from XCoord to YCoord:
    @:to public inline function toYCoord():YCoord return new YCoord(this * 2);

Cool, thanks!

Some examples displaying aritm operator implementations would be great on the wiki page.
Maybe also the Filepath example?

I would be happy to contribute myself, but my knowledge is to shallow...

[Simon Krajewski]

I'll get to that. Until then you can find some examples in our unit tests:
    http://code.google.com/p/haxe/source/browse/trunk/tests/unit/MyAbstract.hx
Most of these are used here:
    http://code.google.com/p/haxe/source/browse/trunk/tests/unit/TestBasetypes.hx#282

Simon

[Cambiata]

Ah! Great source of knowledge! Thanx!

[ScrambledRK]

I wasn't aware of the haxe possibilities - although I should have known considering its haxe we are talking about x)
ty for the heads up

[Mike Welsh]

Wow, I didn't know about the @:op and @:arrayAccess with abstract types! Operator overloading semantics -- didn't think that this was something that was on the roadmap for Haxe.

I was also considering using abstracts to make a FilePath and URI type that would wrap a String and provide lots of helper functions (platform canonical paths, splitting path elements, etc.)

One question, I'm not exactly clear on what the @:coreType metadata does -- does it specify that the abstract type does not wrap an underlying type, but is instead a pure value type?

[Simon Krajewski]

Yes, it's not really intended to be used by users. We use it on basic
types such as Int and Float to basically tell "The runtime knows what to
do with this".

Simon

[Justin Donaldson]

That's a nice explanation of boring old Java abstract classes, but the haxe abstract type is something quite different. ;) You can read an introduction here: http://haxe.org/manual/abstracts

Are there plans to offer boring old Java abstract classes as a feature?  Or is there a way to reproduce this behavior with existing syntax?

Best,

-Justin

--
blog: http://www.scwn.net
twitter: sudojudo

[Simon Krajewski]

Am 21.02.2013 18:41, schrieb Justin Donaldson:

That's a nice explanation of boring old Java abstract classes, but the haxe abstract type is something quite different. ;) You can read an introduction here: http://haxe.org/manual/abstracts

Are there plans to offer boring old Java abstract classes as a feature?  Or is there a way to reproduce this behavior with existing syntax?

Well these classes are really boring, and I'm sure *sunglasses* you can use a macro for that.

Simon

[Cambiata]

So, there should be a zillion of cool uses of abstract types..!
Anywhere there is a single unit entity with defined characteristics.
Just some string types that comes to my mind:

Filepaths
URIs
Emails
Social Security Numbers
Address parts
Phone numbers
Lastnames (not allowing non-letter chars, certain rules about use of spaces, blue blooded and other prefixes "de la Gardie", "O'Toole" etc etc)
Firstnames

So, where to draw the line where use becomes misuse...?

[Cambiata]

Sorry, couldn't resist...!

[Justin Donaldson]

Well these classes are really boring, and I'm sure *sunglasses* you can use a macro for that.

Maybe you can help me rewire my brain then...  let me give a specific example.

I'm looking at a set of color classes.  Colors are awkward in software, because everything has to be represented as RGB eventually.  However, it's not a good inheritance situation, since you don't want to inherit internal data storage fields (R, G, B fields or arrays). I.e. you just want to make sure that a given type can generate a RGB instance somehow, and then define a whole bunch of functionality on top of that.  For the given example, a new color type (HSL, HSV, CMYK, etc.) only has to override the toRGBX() and the clone() methods.  

Here's a partial Color class, that defines two (hackish) abstract methods.  Extending classes just need to define those two methods, and they get the rest of the Color methods for free.  What's a good alternative to this approach?  Relying on a runtime error here seems... crude... for the self respecting Haxe developer. :)

class Color {

public function toRGBX() : RGBX

{

return throw "abstract method, must override";  // *** abstract? ***

}

public function clone() : Color

{

return throw "abstract method, must override"; // *** abstract? ***

}

public function toHex(prefix = "#")

{

return toRGBX().toHex(prefix);

}

public function toCSS3() {

return toRGBX().toCSS3();

}

public function toString()

{

return toRGBX().toString();

}

public function toCSS3Alpha(alpha : Float)

{

return toRGBX().toCSS3Alpha(alpha);

}

public function toStringAlpha(alpha : Float)

{

return toRGBX().toStringAlpha(alpha);

}

public function equalRGB(other : Color)

{

var a = toRGBX(),

b = other.toRGBX();

return a.red == b.red && a.green == b.green && a.blue == b.blue;

}

}

 

[Justin Donaldson]

So, where to draw the line where use becomes misuse...?

This feature is probably one of the most interesting of the pending RC, but it makes a fuzzy line that two or more people might disagree about.  I'm very happy to try it out in a few cases.

A few of your examples involve "not allowing" something, which I don't think is a good way of using this behavior.  E.g., if  file path is invalid, what would toString() return?  You'd have to return a special result, and check for it... it doesn't seem to give you much benefit.

However, there are other situations where you want to define a method that guarantees a valid auto cast.  I think html escaping falls in that camp, there are plenty of others...

-Justin

[Cambiata]

Thank you for input, Justin!

 

A few of your examples involve "not allowing" something, which I don't think is a good way of using this behavior.  E.g., if  file path is invalid, what would toString() return?  You'd have to return a special result, and check for it... it doesn't seem to give you much benefit.

 

Hm, I think this "not allowing" is exactly why the abstract types attract me!

The Int type could never hold 123.45, it does not allow it!
The Email type could never hold "Jonas Nyström", it does not allow it.

Thus, in the file path case, an invalid file path should never exist - no toString() return problem!
In my world, this would "abstract away" some of the most common problem sources in my applications.
Knowing that I can trust the cornerstone data to be nothing but absolutely valid (accordings to the type rules) would be great!
It would lower the validation DRY factor a lot!

Well, I'm thinking loud here...
It will be very exciting to see in what ways the Haxe 3 abstract type will change our solutions!

[Alexander Kuzmenko]

+1 to Justin's question.

I came from PHP and was really sad to know, haxe has no abstracts like this: http://php.net/manual/en/language.oop5.abstract.php

In short: abstract classes is like interfaces but with some common logic already implemented. And compiller just won't build my project if i forgot to implement any abstract methods in extending classes.

This is much better approach, than getting runtime surprises with "throw"-workarounds :)

пятница, 22 февраля 2013 г., 4:57:14 UTC+4 пользователь Justin Donaldson написал:

[Fabien Antoine]

Is there also a @:fieldAccess meta planned?

Le 21/02/2013 18:32, Mike Welsh a �crit :

[Andy Li]

I've just tried: https://gist.github.com/andyli/5011520

It merely gives an error when there is a public constructor in abstract class.

I'm not sure if it is sufficient.

Best,

Andy

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Haxe" group.

To unsubscribe from this group and stop receiving emails from it, send an email to haxelang+u...@googlegroups.com.

[Simon Krajewski]

Am 22.02.2013 01:57, schrieb Justin Donaldson:

Well these classes are really boring, and I'm sure *sunglasses* you can use a macro for that.

Maybe you can help me rewire my brain then...  let me give a specific example.

I'm looking at a set of color classes.  Colors are awkward in software, because everything has to be represented as RGB eventually.  However, it's not a good inheritance situation, since you don't want to inherit internal data storage fields (R, G, B fields or arrays). I.e. you just want to make sure that a given type can generate a RGB instance somehow, and then define a whole bunch of functionality on top of that.  For the given example, a new color type (HSL, HSV, CMYK, etc.) only has to override the toRGBX() and the clone() methods.  

I didn't put too much thought into it, but shouldn't this be sufficient?
https://gist.github.com/Simn/5011604

Simon

[Alexander Kuzmenko]

Wow! That's it, thanks )

пятница, 22 февраля 2013 г., 11:49:05 UTC+4 пользователь Simon Krajewski написал:

[Andy Li]

Oh, seems mine is a little bit more complete than Simon's :) , which:

1. Simon's need to put @:abstract in methods, mine detects method without body.
2. Mine allows extending an abstract class and still being abstract (let further subclass implements).

Anyway, it is rather easy to implement one using macros. 

Cheers,

Andy

--

[Simon Krajewski]

Am 22.02.2013 09:21, schrieb Andy Li:

Oh, seems mine is a little bit more complete than Simon's :) , which:

1. Simon's need to put @:abstract in methods, mine detects method without body.
2. Mine allows extending an abstract class and still being abstract (let further subclass implements).

Anyway, it is rather easy to implement one using macros.

Oh, I didn't see yours and yes, it looks more complete. I just made a quick sketch to show that it's possible.

Simon

[Simon Richardson]

Cheers guys :-) One less thing to look into.

[Justin Donaldson]

Thanks for the tips and code examples, two really good gists.  

It seems awkward to use a macro pattern for this, but it's fine for me.

Best,

-Justin

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haxelang+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Justin Donaldson]

On Thu, Feb 21, 2013 at 8:19 PM, Cambiata <jona...@gmail.com> wrote:

Thank you for input, Justin!

 

A few of your examples involve "not allowing" something, which I don't think is a good way of using this behavior.  E.g., if  file path is invalid, what would toString() return?  You'd have to return a special result, and check for it... it doesn't seem to give you much benefit.

 

Hm, I think this "not allowing" is exactly why the abstract types attract me!

The Int type could never hold 123.45, it does not allow it!
The Email type could never hold "Jonas Nyström", it does not allow it.

Thus, in the file path case, an invalid file path should never exist - no toString() return problem!
In my world, this would "abstract away" some of the most common problem sources in my applications.
Knowing that I can trust the cornerstone data to be nothing but absolutely valid (accordings to the type rules) would be great!
It would lower the validation DRY factor a lot!

I still don't see how the type checking will catch every case, it seems that the run time will have to catch certain errors.  E.g. what would happen with an invalid directory here:

var abstract_directory:FilePath = "/some/invalid/directory/test.txt"

 

Well, I'm thinking loud here...
It will be very exciting to see in what ways the Haxe 3 abstract type will change our solutions!

I agree, I think they're going to be a perfect fit for certain cases.

Best,

-Justin

[Cauê Waneck]

Oh I see Simon writing haxe now as if it were ocaml

but with a nicer syntax ;)

2013/2/22 Simon Krajewski <si...@haxe.org>

--

[Cambiata]

@Justin:

I still don't see how the type checking will catch every case, it seems that the run time will have to catch certain errors.  E.g. what would happen with an invalid directory here:

var abstract_directory:FilePath = "/some/invalid/directory/test.txt"

Aboslutely, but that's another problem. That applies to any type.
(A Float with the value 3.41 is wrong if it's supposed to be 3.14. But it's still a valid Float!)

The point is that I can trust the entity itself (Filepath) to be valid according to filepath rules.

[Raoul Duke]

uh, what about haxe 2, at least?

[Justin Donaldson]

here's a version for haxe 2:

https://gist.github.com/jdonaldson/5027770

On Sun, Feb 24, 2013 at 7:10 PM, Raoul Duke <rao...@gmail.com> wrote:

uh, what about haxe 2, at least?

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haxelang+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Raoul Duke]

On Sun, Feb 24, 2013 at 8:44 PM, Justin Donaldson <jdona...@gmail.com> wrote:
> here's a version for haxe 2:
> https://gist.github.com/jdonaldson/5027770

w00t thanks i will try it as apparently this is the best of all the options.

[Raoul Duke]

> here's a version for haxe 2:
> https://gist.github.com/jdonaldson/5027770

in case some other poor schmuck is following in my footsteps: if you
don't want that to be in the top-level package, and you move it, you
also have to put the package path in the @:autoBuild(...) line,
otherwise you get: Class not found : AbstractClassBuilder.

just another nail in the coffin.

[Raoul Duke]

> here's a version for haxe 2:
> https://gist.github.com/jdonaldson/5027770

i don't get it, or i'm missing something about the syntax.

with a java abstract method m() in an abstract class A, i can call m()
from another method inside A with no problem. the compiler will make
sure subclasses that aren't abstract implement m() so things all work
right at runtime. this is what i want. i haven't seen that that is
possible here?

i do not want to supply an empty routine in the abstract class.
because that isn't any different in terms of static checking safety
than if i just didn't use this macro and had the body be to throw an
exception when not overridden.

[Raoul Duke]

> i don't get it, or i'm missing something about the syntax.

ok i see where i'm being thick: as the error message kindly points
out, now that i pay attention, i changed my constructor to private.

things are w00ty again.

[Raoul Duke]

On Sun, Feb 24, 2013 at 8:44 PM, Justin Donaldson <jdona...@gmail.com> wrote:

> here's a version for haxe 2:
> https://gist.github.com/jdonaldson/5027770

that did not work well for me. afaict it got confused about how many
instances of a missing function there were when the inheritance
hierarchy was larger than the example in the gist. what i did that
fixed it for me, and i would hazard to guess that otherwise the
original version is broken, is to use a Hash<String> as (very) poor
man's Set for the absFields.

[Andy Li]

Please post a minimum example which the macro does not work well.

So that we can improve it.

Best,

Andy

[Raoul Duke]

https://gist.github.com/raould/94ade0d1d6b1fc2915af

is what i have so far, with the (very) poor man's set fix.

i am currently fighting with how the Context becomes borked.

[Andy Li]

Please, we need the failing example (but not your improved version though it is helpful), such that we know what cases need to be covered.

[Raoul Duke]

this is just about everything i've hit all wrapped up together.

-java
-main Hell
-lib tink_lang
--next
-neko n.n
-main Hell
-lib tink_lang

interface IFoo {
var foo(default,null):Int;
}

class Helper
implements IFoo {
static var sFoo:Int = 0;
public var foo(default,null):Int;
public function new() { this.foo = sFoo++; }
}

class ASuper
implements AbstractClass {
private function new() {}
public function fnord();
}

class B1
extends ASuper {
public function new() { super(); }
override public function fnord() {}
}

class ASub
extends ASuper,
implements AbstractClass {
private function new() { super(); }
public function dronf();
}

class B2
extends ASub {
public function new() { super(); }
override public function fnord() {}
override public function dronf() {}
}

class Hell {
public static function main() {
var o1 = new B1();
trace( o1 );
var o2 = new B2();
trace( o2 );
}
}

[Raoul Duke]

well, yet another rub that surely makes me laugh all the way to the
bank, not: i think you can't just "macro return throw 'error'" since
an abstract :Void function shouldn't be trying to return anything!
this shows up when targeting cpp.

[Raoul Duke]

and since those are abstract methods, there is nothing in
cls.get().fields.get() for them, which means we cannot find out what
their declared return type is, which means we're sol as far as i
understand so far. sheezuz.

[Raoul Duke]

> and since those are abstract methods, there is nothing in
> cls.get().fields.get() for them, which means we cannot find out what
> their declared return type is, which means we're sol as far as i
> understand so far. sheezuz.

oh. wait, i should try something like Context.getBuildFields() then
Field.kind:FieldType and Function.ret:Null<ComplexType> but then i
don't know what to do to check to see if it is just a ":Void" return
declaration.

[Raoul Duke]

better, but still not working 100%.

https://gist.github.com/raould/94ade0d1d6b1fc2915af

[Raoul Duke]

> better, but still not working 100%.
> https://gist.github.com/raould/94ade0d1d6b1fc2915af

ok it was a problem with my code and some serialized stuff, i
regenerated it and now things work with that exact gist.

[Raoul Duke]

well, last but not least, iiuc it doesn't play well with tink.lang.Cls
@:forw. when i try to satisfy the missing abstract method by using
@:forw to something that has it, that doesn't seem to flow through,
and i get an error that the thing-trying-to-forward is still abstract.

[Andy Li]

I've updated my version at https://gist.github.com/andyli/5011520

It should now works in both haxe 2.10 and 3.

And as suggested I replaced the Array with a Map(or Hash in haxe 2), although the real problem is the build macro got called twice somewhere.

Problem of Void returning abstract function in cpp target is fixed too.

For tink support, it may worth trying to rearrange the "implements", such that AbstractClassBuilder is called last.

But I'm not sure if it is possible.

Raoul, I welcome your comments and discussion, but please try not to reply multiple times with very short message, this is not a chatroom.
For further issue, please comment on the gist page, such that this thread about abstract type wouldn't be flooded ;)

Best,

Andy

[Raoul Duke]

On Tue, Feb 26, 2013 at 2:25 AM, Andy Li <an...@onthewings.net> wrote:
> I've updated my version at https://gist.github.com/andyli/5011520
> It should now works in both haxe 2.10 and 3.
> And as suggested I replaced the Array with a Map(or Hash in haxe 2),
> although the real problem is the build macro got called twice somewhere.
> Problem of Void returning abstract function in cpp target is fixed too.

you're welcome! :-)

> For tink support, it may worth trying to rearrange the "implements", such
> that AbstractClassBuilder is called last.
> But I'm not sure if it is possible.

(gosh, maybe if these things were considered important enough for real
software engineering that haxe addressed them in the core compiler...

...but since that is apparently a pipe dream) i wonder if there's a
way to make the AbstractClass macro run 2 times, so that it can happen
once more after other macros also get a chance to contribute to the
final class.

[Raoul Duke]

> I've updated my version at https://gist.github.com/andyli/5011520

ok i switched to using that and it does, indeed, all work for me. thanks!